Miniscript - Bitcoin network graphs

Groestlcoin 6th Anniversary Release

Introduction

Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything.
The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years.
In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.

UPDATED - Groestlcoin Core 2.18.2

This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables.
NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.

How to Upgrade?

Windows
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer.
OSX
If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications.
Ubuntu
http://groestlcoin.org/forum/index.php?topic=441.0

Other Linux

http://groestlcoin.org/forum/index.php?topic=97.0

Download

Download the Windows Installer (64 bit) here
Download the Windows Installer (32 bit) here
Download the Windows binaries (64 bit) here
Download the Windows binaries (32 bit) here
Download the OSX Installer here
Download the OSX binaries here
Download the Linux binaries (64 bit) here
Download the Linux binaries (32 bit) here
Download the ARM Linux binaries (64 bit) here
Download the ARM Linux binaries (32 bit) here

Source

ALL NEW - Groestlcoin Moonshine iOS/Android Wallet

Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network.
GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.

Features

Download

iOS
Android

Source

ALL NEW! – HODL GRS Android Wallet

HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled.
HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user.
Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.

Features

Download

Main Release (Main Net)
Testnet Release

Source

ALL NEW! – GroestlcoinSeed Savior

Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases.
This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats.
To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.

Features

Live Version (Not Recommended)

https://www.groestlcoin.org/recovery/

Download

https://github.com/Groestlcoin/mnemonic-recovery/archive/master.zip

Source

ALL NEW! – Vanity Search Vanity Address Generator

NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator.
VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline.
If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address.
VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase.
VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).

Features

Usage

https://github.com/Groestlcoin/VanitySearch#usage

Download

Source

ALL NEW! – Groestlcoin EasyVanity 2020

Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet.
If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).

Features

Download

Source

Remastered! – Groestlcoin WPF Desktop Wallet (v2.19.0.18)

Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode.
This wallet was previously deprecated but has been brought back to life with modern standards.

Features

Remastered Improvements

Download

Source

ALL NEW! – BIP39 Key Tool

Groestlcoin BIP39 Key Tool is a GUI interface for generating Groestlcoin public and private keys. It is a standalone tool which can be used offline.

Features

Download

Windows
Linux :
 pip3 install -r requirements.txt python3 bip39\_gui.py 

Source

ALL NEW! – Electrum Personal Server

Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node.
It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node.
Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine.
Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in.
Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet.
Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.

Features

Download

Windows
Linux / OSX (Instructions)

Source

UPDATED – Android Wallet 7.38.1 - Main Net + Test Net

The app allows you to send and receive Groestlcoin on your device using QR codes and URI links.
When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.

Changes

Download

Main Net
Main Net (FDroid)
Test Net

Source

UPDATED – Groestlcoin Sentinel 3.5.06 (Android)

Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets).
Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet.
Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.

Changes

Download

Source

UPDATED – P2Pool Test Net

Changes

Download

Pre-Hosted Testnet P2Pool is available via http://testp2pool.groestlcoin.org:21330/static/

Source

submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

Spedn 0.2 released and ready for Nov 19 protocol upgrade

Spedn 0.2 released and ready for Nov 19 protocol upgrade

https://preview.redd.it/xd5ww7lygpy31.png?width=478&format=png&auto=webp&s=93de83fc0c17c622d89eaba257e18352b7cb1481
Spedn is a high level smart contracts language for Bitcoin Cash. A new major version 0.2 has just been released.
This is 15th Nov 2019 hard-fork compatibility update with a bunch of changes and new features.
  • Introducing an array type with syntax [type; length], for example [Sig; 3] signatures, [byte; 10] message. The compiler type-checks the lengths so for example a type of message . message expression will be inferred as [byte; 20].
  • Syntax for tuple assignment now allows its items to be of different type: (int a, Sig b, PubKey c) = expr;
  • Array elements can be accessed with x[i] syntax.
  • Introducing a bit type. In practice only arrays of bits are useful, as they represent a type of checkbits argument in the checkMultiSig function which was upgraded for Schnorr support. Bit array literal is also introduced, ex. [bit; 5] checkbits = 0b00110.
  • As mentioned - checkMultiSig accepts an additional checkbits argument, as described in Nov 15 hard-fork spec.
  • For a byte array of unknown size there is [byte] type which replaces the former bin type.
  • Introducing (UTF-8) string literals, ex. [byte] message = "Hello, World";.
  • Introducing custom type declarations (type aliases) which can be placed before contract declarations and then used as any other type in the contract. Ex. type Message = [byte; 10];. Actually, Sig, DataSig, PubKey, Ripemd160, Sha1, Sha256, Time and TimeSpan are defined internally as aliases.
  • Introducing separator; statement that compiles to OP_CODESEPARATOR.
  • Introducing fail; statement that compiles to OP_RETURN.
  • Introducing checkSize(x) function that returns true if the runtime size of a byte array matches the declared type.
  • Variable names can now contain underscores, ex. [byte] my_string.
For developers of v0.1 there's a short migration guide which shows how to adjust an old contract code to the new syntax.
submitted by pein_sama to btc [link] [comments]

PSA: Guide on how to recover your lost Segwit coins using Electron Cash

How to get your recovered SegWit funds using Electron Cash

Background

Thousands of BCH on thousands of coins that were accidentally send to Segwit 3xxx addresses were recovered by BTC.TOP in block 582705.
This was a wonderful service to the community. This had to be done quickly as the coins were anyone can spend and needed to be sent somewhere. This all had to be done before thieves could get their dirty paws on them.
So.. How were they recovered? Did BTC.TOP just take the coins for themselves? NO: They were not taken by BTC.TOP. This would be wrong (morally), and would open them up to liability and other shenanigans (legally).
Instead --BTC.TOP acted quickly and did the legally responsible thing with minimal liability. They were sent on to the intended destination address of the SegWit transaction (if translated to BCH normal address).
This means BTC.TOP did not steal your coins and/or does not have custody of your funds!
But this does mean you now need to figure out how to get the private key associated with where they were sent -- in order to unlock the funds. (Which will be covered below).
Discussions on why this was the most responsible thing to do and why it was done this way are available upon request. Or you can search this subreddit to get to them.

Ok, so BTC.TOP doesn't have them -- who does?

You do (if they were sent to you)! Or -- the person / address they were sent to does!

HUH?

The Segwit transactions have a bad/crazy/messed-up format which contains an output (destination) which contains a hash of a public key inside. So they "sort of" contain a regular bitcoin address inside of them, with other Segwit garbage around them. This hash was decoded and translated to a regular BCH address, and the funds were sent there.
Again: The funds were forwarded on to a regular BCH address where they are safe. They are now guarded by a private key -- where they were not before (before they were "anyone can spend"). It can be argued this is the only reasonable thing to have done with them (legally and morally) -- continue to send them to their intended destination. This standard, if it's good enough for the US Post Office and Federal Mail, is good enough here. It's better than them being stolen.

Ok, I get it... they are on a regular BCH address now. The address of the destination of the Tx, is it?

Yes. So now a regular BCH private key (rather than anyone can spend) is needed to spend them further. Thus the Segwit destination address you sent them to initially was effectively translated to a BCH regular address. It's as if you posted a parcel with the wrong ZIP code on it -- but the USPS was nice enough to figure that out and send it to where you intended it to go.

Why do it this way and not return to sender?

Because of the ambiguity present-- it's not entirely clear which sender to return them to. There is too much ambiguity there, and would have led to many inputs not being recovered in a proper manner. More discussion on this is available upon request.

Purpose of this guide

This document explains how to:
Complications to watch out for:

Step 1: Checking where your coins went

To verify if this recovery touched one of your lost coins: look for the transaction that spent your coins and open it on bch.btc.com explorer.

Normal aka "P2PKH"

Let’s take this one for example.
Observe the input says:
P2SH 160014d376cf1baff9eeed943d58551d53c48377adb98c 
And the output says:
P2PKH OP_DUP OP_HASH160 d376cf1baff9eeed943d58551d53c48377adb98c OP_EQUALVERIFY OP_CHECKSIG 
Notice a pattern?
The fact that these two highlighted hexadecimal strings are the same means that the funds were forwarded to the identical public key, and can be spent by the private key (corresponding to that public key) if it is imported into a Bitcoin Cash wallet.

Multisig aka "P2SH"

If the input starts with “P2SH 220020…”, as in this example, then your segwit address is a script -- probably a multisignature. While the input says “P2SH 22002019aa2610492ee2c18605597136294596d4f0f9bc6ce0974ed3a975d65da4ca1e”, the output says “P2SH OP_HASH160 21bdc73fb15b3bb7bd1be365e92447dc2a44e662 OP_EQUAL”. These two strings actually correspond to the same script, but they are different in content and length due to segwit’s design. However, you just need to RIPEMD160 hash the first string and compare to the second -- you can check this by entering the input string (after the 220020 part) into this website’s Binary Hash field and checking the resulting RIPEMD160 hash. The resulting hash is 21bdc73fb15b3bb7bd1be365e92447dc2a44e662, which corresponds to the output hex above, and this means the coins were forwarded to the same spending script but in "non-segwit form". You will need to re-assemble the same multi-signature setup and enough private keys on a Bitcoin Cash wallet. (Sorry for the succinct explanation here. Ask in the comments for more details perhaps.)

No match -- what?!

If the string does not match (identically in the Normal case above, or after properly hashing in the Multisig case above), then your coins were sent elsewhere, possibly even taken by an anonymous miner. :'(

Step 2: How To Do the Recovery

Recover "Normal" address transactions (P2PKH above)

This is for recoveries where the input string started with “160014”.
Option 1 (BIP39 seed):
Option 2 (single key):
Option 3 (xprv -- many keys):
Code:
mkey = "yprvAJ48Yvx71CKa6a6P8Sk78nkSF7iqqaRob1FN7Jxsqm3L52K8XmZ7EtEzPzTUWXAaHNfN4DFAuP4cdM38yrE6j3YifV8i954hyD5rhPyUNVP" from electroncash.bitcoin import DecodeBase58Check, EncodeBase58Check EncodeBase58Check(b'\x04\x88\xad\xe4'+DecodeBase58Check(mkey)[4:]) 
Option 4 (hardware wallet):

How to Recover Multisignature wallets (P2WSH-in-P2SH in segwit parlance)

This is for recoveries where the input string started with "220020.
Please read the above instructions for how to import single keys. You will need to do similar but taking care to reproduce the same set of multisignature keys as you had in the BTC wallet. Note that Electron Cash does not support single-key multisignature, so you need to use the BIP39 / xprv approach.
If you don’t observe the correct address in Electron Cash, then check the list of public keys by right clicking on an address, and compare it to the list seen in your BTC wallet. Also ensure that the number of required signers is identical.
submitted by NilacTheGrim to btc [link] [comments]

Transcript of Open Developer Meeting in Discord - 7/19/2019

[Dev-Happy] BlondfrogsLast Friday at 3:58 PM
Hey everyone. The channel is now open for the dev meeting.
LSJI07 - MBITLast Friday at 3:58 PM
Hi
TronLast Friday at 3:59 PM
Hi all!
JerozLast Friday at 3:59 PM
:wave:
TronLast Friday at 3:59 PM
Topics: Algo stuff - x22rc, Ownership token for Restricted Assets and Assets.
JerozLast Friday at 4:00 PM
@Milo is also here from coinrequest.
MiloLast Friday at 4:00 PM
Hi :thumbsup:
Pho3nix Monk3yLast Friday at 4:00 PM
welcome, @Milo
TronLast Friday at 4:00 PM
Great.
@Milo Was there PRs for Android and iOS?
MiloLast Friday at 4:01 PM
Yes, I've made a video. Give me a second I'll share it asap.
JerozLast Friday at 4:02 PM
I missed the iOS one.
MiloLast Friday at 4:02 PM
Well its 1 video, but meant for all.
JerozLast Friday at 4:02 PM
Ah, there's an issue but no pull request (yet?)
https://github.com/RavenProject/ravenwallet-ios/issues/115
[Dev-Happy] BlondfrogsLast Friday at 4:03 PM
nice @Milo
MiloLast Friday at 4:04 PM
Can it be that I have no video post rights?
JerozLast Friday at 4:05 PM
In discord?
MiloLast Friday at 4:05 PM
yes?
[Dev-Happy] BlondfrogsLast Friday at 4:05 PM
just a link?
JerozLast Friday at 4:05 PM
Standard version has a file limit afaik
Pho3nix Monk3yLast Friday at 4:05 PM
try now
gave permissions
MiloLast Friday at 4:05 PM
it's not published yet on Youtube, since I didn't knew when it would be published in the wallets
file too big. Hold on i'll put it on youtube and set it on private
LSJI07 - MBITLast Friday at 4:06 PM
no worries ipfs it...:yum:
Pho3nix Monk3yLast Friday at 4:06 PM
ok, just send link when you can
[Dev-Happy] BlondfrogsLast Friday at 4:07 PM
So guys. We released Ravencoin v2.4.0!
JerozLast Friday at 4:08 PM
If you like the code. Go update them nodes! :smiley:
[Dev-Happy] BlondfrogsLast Friday at 4:08 PM
We are recommending that you are upgrading to it. It fixes a couple bugs in the code base inherited from bitcoin!
MiloLast Friday at 4:08 PM
https://www.youtube.com/watch?v=t\_g7NpFXm6g&feature=youtu.be
sorry for the hold up
YouTube
Coin Request
Raven dev Gemiddeld
LSJI07 - MBITLast Friday at 4:09 PM
thanks short and sweet!!
KAwARLast Friday at 4:10 PM
Is coin request live on the android wallet?
TronLast Friday at 4:10 PM
Nice video.
It isn't in the Play Store yet.
Pho3nix Monk3yLast Friday at 4:10 PM
Well, this is the first time in a while where we have this many devs online. What questions do y'all have?
LSJI07 - MBITLast Friday at 4:11 PM
Algo questions?
Pho3nix Monk3yLast Friday at 4:11 PM
sure
KAwARLast Friday at 4:11 PM
KK
LSJI07 - MBITLast Friday at 4:12 PM
what are the proposed 22 algos in x22r? i could only find the original 16 plus 5 on x21.
TronLast Friday at 4:12 PM
Likely the 5 from x21 and find one more.
We need to make sure they're all similar in time profile.
liqdmetalLast Friday at 4:14 PM
should we bother fixing a asic-problem that we dont know exists for sure or not?
TronLast Friday at 4:14 PM
That's the 170 million dollar question.
[Dev-Happy] BlondfrogsLast Friday at 4:14 PM
I would prefer to be proactive not reactive.
imo
JerozLast Friday at 4:14 PM
same
LSJI07 - MBITLast Friday at 4:15 PM
RIPEMD160 is a golden oldie but not sure on hash speed compared to the others.
liqdmetalLast Friday at 4:15 PM
in my mind we should focus on the restricted messaging etc
Sevvy (y rvn pmp?)Last Friday at 4:15 PM
probably won't know if the action was needed until after you take the action
liqdmetalLast Friday at 4:15 PM
we are at risk of being interventionistas
acting under opacity
TronLast Friday at 4:15 PM
Needs to spit out at least 256 bit. Preferably 512 bit.
LSJI07 - MBITLast Friday at 4:15 PM
ok
TronLast Friday at 4:15 PM
If it isn't 512 bit, it'll cause some extra headache for the GPU mining software.
liqdmetalLast Friday at 4:16 PM
i seek to avoid iatrogenics
TronLast Friday at 4:16 PM
Similar to the early problems when all the algos except the first one were built for 64-bytes (512-bit) inputs.
Had to look that one up. TIL iatrogenics
JerozLast Friday at 4:17 PM
I have to google most of @liqdmetal's vocabulary :smile:
liqdmetalLast Friday at 4:17 PM
@Tron tldr: basically the unseen, unintended negative side effects of the asic "cure"
Sevvy (y rvn pmp?)Last Friday at 4:18 PM
10 dolla word
liqdmetalLast Friday at 4:19 PM
we need a really strong case to intervene in what has been created.
TronLast Friday at 4:19 PM
I agree. I'm less concerned with the technical risk than I am the potential split risk experienced multiple times by Monero.
Sevvy (y rvn pmp?)Last Friday at 4:20 PM
tron do you agree that forking the ravencoin chain presents unique risks compared to other chains that aren't hosting assets?
JerozLast Friday at 4:21 PM
Yes, if you fork, you need to figure out for each asset which one you want to support.
Sevvy (y rvn pmp?)Last Friday at 4:21 PM
yeah. and the asset issuer could have a chain preference
TronLast Friday at 4:22 PM
@Sevvy (y rvn pmp?) Sure. Although, I'd expect that the asset issuers will be honor the assets on the dominant chain. Bigger concern is the branding confusion of multiple forks. See Bitcoin, Bitcoin Cash, Bitcoin SV for an example. We know they're different, but do non-crypto folks?
Hans_SchmidtLast Friday at 4:22 PM
I thought that the take-away from the recently published analyses and discussions was that ASICs for RVN may be active, but if so then they are being not much more effective than GPUs.
Sevvy (y rvn pmp?)Last Friday at 4:22 PM
agreed on all accounts there tron
TronLast Friday at 4:23 PM
I'm not yet convinced ASICs are on the network.
KAwARLast Friday at 4:23 PM
It would be better to damage an asic builder by forking after they made major expenses. Creating for them the type of deficit that could be negated by just buying instead of mining. Asic existence should be 100 percent confirmed before fork.
liqdmetalLast Friday at 4:23 PM
170million dollar question is right.lol
TronLast Friday at 4:24 PM
I've had someone offer to connect me to the folks at Fusion Silicon.
Sevvy (y rvn pmp?)Last Friday at 4:25 PM
yes. and if they are active on the network they are not particularly good ASICs
which makes it a moot point probably
TronLast Friday at 4:26 PM
The difficult part of this problem is that by the time everyone agrees that ASICs are problematic on the network, then voting the option in is likely no longer an option.
Sevvy (y rvn pmp?)Last Friday at 4:26 PM
yes. part of me wonders if we would say "okay, the clock on the asic countdown is reset by this new algo. but now the race is on"
[Dev-Happy] BlondfrogsLast Friday at 4:26 PM
There are always risks when making a change that will fork the network. We want wait to long though, as tron said. It wont be a voting change. it will be a mandatory change at a block number.
Sevvy (y rvn pmp?)Last Friday at 4:26 PM
acknowledge the inevitable
MiloLast Friday at 4:27 PM
I had just a small question from my side. When do you think the android version would be published, and do you maybe have a time-frame for the others?
TronLast Friday at 4:27 PM
Quick poll. How would everyone here feel about a BIP9 option - separate from the new features that can be voted in?
KAwARLast Friday at 4:27 PM
Maybe voting should not be a strictly blockchain vote. A republic and a democratic voice?
[Dev-Happy] BlondfrogsLast Friday at 4:27 PM
@Milo We can try and get a beta out next week, and publish soon after that.
MiloLast Friday at 4:28 PM
@[Dev-Happy] Blondfrogs :thumbsup::slight_smile:
[Dev-Happy] BlondfrogsLast Friday at 4:28 PM
BIP9 preemptive vote. I like it.
TronLast Friday at 4:30 PM
The advantage to a BIP9 vote is that it puts the miners and mining pools at a clear majority before activation.
LSJI07 - MBITLast Friday at 4:30 PM
Centralisation is inevitable unless we decide to resist it. ASIC's are market based and know the risks and rewards possible. A key step in resisting is sending a message. An algo change to increase asic resistance is imho a strong message. A BIP9 vote now would also be an indicator of bad actors early....
TronLast Friday at 4:30 PM
The disadvantage is that it may not pass if the will isn't there.
LSJI07 - MBITLast Friday at 4:30 PM
Before assets are on main net and cause additional issues.
KAwARLast Friday at 4:31 PM
I am not schooled in coding to have an educated voice. I only understand social problems and how it affects the economy.
SpyderDevLast Friday at 4:31 PM
All are equal on RVN
TronLast Friday at 4:31 PM
It is primarily a social problem. The tech change is less risky and is easier than the social.
LSJI07 - MBITLast Friday at 4:32 PM
All can have a share....people who want more of a share however pay for the privilege and associated risks.
KAwARLast Friday at 4:33 PM
Assets and exchange listings need to be consistent and secure.
brutoidLast Friday at 4:36 PM
I'm still not entirely clear on what the overall goal to the algo change is? Is it just to brick the supposed ASICs (unknown 45%) which could still be FPGAs as seen from the recent block analysis posted in the nest. Is the goal to never let ASICs on? Is it to brick FPGAs ultimately. Are we making Raven strictly GPU only? I'm still unclear
LSJI07 - MBITLast Friday at 4:37 PM
What about the future issue of ASICs returning after a BIP9 fork "soon"? Are all following the WP as a community? i.e asic resistant or are we prepared to change that to asic resistant for early coin emission. Ideally we should plan for the future. Could the community make a statement that no future algo changes will be required to incentivise future public asic manufacturers?
Lol. Same question @brutoid
brutoidLast Friday at 4:37 PM
Haha it is
You mind-beamed me!
[Dev-Happy] BlondfrogsLast Friday at 4:38 PM
The is up to the community.
Currently, the feel seems like the community is anti asic forever.
The main issue is getting people to upgrade.
KAwARLast Friday at 4:38 PM
Clarity is important. Otherwise we are attacking windmills like Don Quixote.
brutoidLast Friday at 4:39 PM
I'm not getting the feeling of community ASIC hate if the last few weeks of discussion are anything to go by?
Hans_SchmidtLast Friday at 4:39 PM
A unilateral non-BIP9 change at a chosen block height is a serious thing, but anti-ASIC has been part of the RVN philosophy since the whitepaper and is therefore appropriate for that purpose.
[Dev-Happy] BlondfrogsLast Friday at 4:39 PM
We can use the latest release as an example. It was a non forking release, announced for 2 weeks. and only ~30% of the network has upgraded.
TronLast Friday at 4:39 PM
@Hans_Schmidt Well said.
liqdmetalLast Friday at 4:40 PM
I'm not concerned about a "asic hardware problem" so much as I believe it more likely what we are seeing is several big fish miners (perhaps a single really big fish). For now I recommend standing pat on x16r. In the future I can see an algo upgrade fork to keep the algo up to date. If we start fighting against dedicated x16r hashing machines designed and built to secure our network we are more likely to go down in flames. The custom SHA256 computers that make the bitcoin the most secure network in existence are a big part of that security. If some party has made an asic that performs up to par or better than FPGA or GPU on x16r, that is a positive for this network, a step towards SHA256 security levels. It is too bad the community is in the dark regarding their developments. Therefore I think the community has to clarify its stance towards algorithm changes. I prefer a policy that will encourage the development of mining software, bitstreams and hardware by as many parties as possible. The imminent threat of ALGO fork screws the incentive up for developers.
JerozLast Friday at 4:40 PM
@brutoid the vocal ones are lenient towards asics, but the outcome of the 600+ votes seemed pretty clear.
brutoidLast Friday at 4:40 PM
This is my confusion
TronLast Friday at 4:41 PM
More hashes are only better if the cost goes up proportionally. Machines that do more hashes for less $ doesn't secure the network more, and trends towards centralization.
JerozLast Friday at 4:41 PM
I would argue for polling ever so often as it certainly will evolve dynamically with the state of crypto over time.
TronLast Friday at 4:41 PM
Measure security in two dimensions. Distribution, and $/hash.
liqdmetalLast Friday at 4:41 PM
and volume of hash
traysiLast Friday at 4:42 PM
45% of the hashrate going to one party is unhealthy, and standing pat on x16r just keeps that 45% where it is.
TronLast Friday at 4:42 PM
Volume doesn't matter if the cost goes down. For example, lets say software shows up that does 1000x better than the software from yesterday, and everyone moves to it. That does not add security. Even if the "difficulty" and embedded hashes took 1000x more attempts to find.
brutoidLast Friday at 4:42 PM
My issue is defintely centralization of hash and not so much what machine is doing it. I mine with both GPU and FPGA. Of course, the FPGAs are not on raven
TJayLast Friday at 4:44 PM
easy solution is just to replace a few of 16 current hash functions, without messing with x21r or whatever new shit
TronLast Friday at 4:44 PM
How do folks here feel about allowing CPUs back in the game?
traysiLast Friday at 4:44 PM
Botnets is my concern with CPUs
brutoidLast Friday at 4:44 PM
Botnets is my concern
SpyderDevLast Friday at 4:44 PM
Yes please.
LSJI07 - MBITLast Friday at 4:44 PM
the poll votes seem not very security conscious. More of day miners chasing profits. I love them bless! Imho the future is bright for raven, however these issues if not sorted out now will bite hard long term when asset are on the chain and gpu miners are long gone.....
ZaabLast Friday at 4:45 PM
How has the testing of restricted assets been on the test net?
liqdmetalLast Friday at 4:45 PM
Agreed. I dont think x16r is obsolete like that yet however
[Dev-Happy] BlondfrogsLast Friday at 4:45 PM
@Zaab not enough testing at the moment.
HedgerLast Friday at 4:45 PM
Yes, how is the Testing going?
justinjjaLast Friday at 4:45 PM
Like randomX or how are cpus going to be back in the game?
TronLast Friday at 4:45 PM
@Zaab Just getting started at testing at the surface level (RPC calls), and fixing as we go.
ZaabLast Friday at 4:45 PM
And or any updates on the review of dividend code created by the community
Lokar -=Kai=-Last Friday at 4:45 PM
if the amount of hash the unknown pool has is fixed as standarderror indicated then waiting for the community of FPGAers to get onto raven might be advantageous if the fork doesn't hurt FPGAs.
ZaabLast Friday at 4:45 PM
Can't rememeber who was on it
SpyderDevLast Friday at 4:45 PM
@Zaab But we are working on it...
Lokar -=Kai=-Last Friday at 4:46 PM
more hash for votes
JerozLast Friday at 4:46 PM
@Maldon is, @Zaab
TronLast Friday at 4:46 PM
@Zaab There are unit tests and functional tests already, but we'd like more.
[Dev-Happy] BlondfrogsLast Friday at 4:46 PM
@Zaab Dividend code is currently adding test cases for better security. Should have more update on that next meeting
KAwARLast Friday at 4:46 PM
Absolute democracy seems to resemble anarchy or at least civil war. In EVE online they have a type of community voice that get voted in by the community.
ZaabLast Friday at 4:46 PM
No worries was just curious if it was going as planned or significant issues were being found
Obviously some hiccups are expected
More testing is always better!
TronLast Friday at 4:47 PM
Who in here is up for a good civil war? :wink:
ZaabLast Friday at 4:47 PM
Tron v Bruce. Celebrity fight night with proceeds to go to the RVN dev fund
SpyderDevLast Friday at 4:48 PM
Cagefight or mudpit?
JerozLast Friday at 4:48 PM
talking about dev funds..... :wink:
Pho3nix Monk3yLast Friday at 4:49 PM
and there goes the conversation....
KAwARLast Friday at 4:49 PM
I am trying to be serious...
ZaabLast Friday at 4:49 PM
Sorry back to the ascii topic!
traysiLast Friday at 4:49 PM
@Tron What do we need in order to make progress toward a decision on the algo? Is there a plan or a roadmap of sorts to get us some certainty about what we're going to do?
LSJI07 - MBITLast Friday at 4:50 PM
Could we have 3 no BIP9 votes? No1 Friendly to asics, retain status quo. No2 change to x17r minimal changes etc, with no additional future PoW/algo upgrades. No3. Full Asic resistance x22r and see what happens...
:thonk~1:
Sounds messy....
TronLast Friday at 4:51 PM
Right now we're in research mode. We're building CNv4 so we can run some metrics. If that goes well, we can put together x22rc and see how it performs. It will likely gore everyone's ox. CPUs can play, GPUs work, but aren't dominant. ASICs VERY difficult, and FPGAs will have a tough time.
ZaabLast Friday at 4:51 PM
Yeah i feel like the results would be unreliable
TronLast Friday at 4:51 PM
Is this good, or do we lose everyone's vote?
PlayHardLast Friday at 4:52 PM
Fpga will be dead
Lokar -=Kai=-Last Friday at 4:52 PM
why isn;t a simple XOR or something on the table?
ZaabLast Friday at 4:52 PM
The multiple bip9 that is
Lokar -=Kai=-Last Friday at 4:52 PM
something asic breaking but doesn't greatly complicate ongoing efforts for FPGA being my point.
justinjjaLast Friday at 4:52 PM
How are you going to vote for x22rc?
Because if by hashrate that wouldn't pass.
traysiLast Friday at 4:52 PM
Personally I like the idea of x22rc but I'd want to investigate the botnet threat if CPUs are allowed back in.
TronLast Friday at 4:52 PM
XOR is on the table, and was listed in my Medium post. But, the social risk of chain split remains, for very little gain.
traysiLast Friday at 4:53 PM
@Lokar -=Kai=- A small change means that whoever has 45% can probably quickly adapt.
LSJI07 - MBITLast Friday at 4:53 PM
Research sounds good. x22rc could be reduce to x22r for simplicity...
TronLast Friday at 4:53 PM
x22r is a viable option. No CNv4.
LSJI07 - MBITLast Friday at 4:53 PM
Don't know how much time we have to play with though...
Lokar -=Kai=-Last Friday at 4:53 PM
if they have FPGAs yes if they have ASIC then not so much, but I guess that gets to the point, what exactly are we trying to remove from the network?
PlayHardLast Friday at 4:54 PM
Guys my name is Arsen and we designed x16r fpga on bcus. Just about to release it to the public. I am buzzdaves partner.
Cryptonight
Will kill us
But agreed
Asic is possible on x16r
And you dont need 256 core
Cores
traysiLast Friday at 4:55 PM
Hi Arsen. Are you saying CN will kill "us" meaning RVN, or meaning FPGA?
JerozLast Friday at 4:55 PM
This is what im afraid of ^ an algo change killing FPGA as I have the feeling there is a big fpga community working on this
PlayHardLast Friday at 4:55 PM
Fpgas ))
whitefire990Last Friday at 4:55 PM
I am also about to release X16R for CVP13 + BCU1525 FPGA's. I'm open to algo changes but I really don't believe in CPU mining because of botnets. Any CNv4 shifts 100% to CPU mining, even if it is only 1 of the 22 functions.
Lokar -=Kai=-Last Friday at 4:55 PM
namely FPGAs that aren;t memory equipped
like fast mem
not ddr
PlayHardLast Friday at 4:55 PM
Hbm non hbm
Cryptonight
whitefire990Last Friday at 4:56 PM
Right now with both Buzzdave/Altered Silicon and myself (Zetheron) about to release X16R for FPGA's, then the 45% miner's share will decrease to 39% or less.
PlayHardLast Friday at 4:56 PM
Will be dead for fpga
LSJI07 - MBITLast Friday at 4:56 PM
sound so x22r is fpga "friendly" ... more so than asic anyway...
PlayHardLast Friday at 4:56 PM
But a change must be planned
X16r is no way possible to avoid asics
TJayLast Friday at 4:56 PM
@LSJI07 - MBIT I would say less friendly...
whitefire990Last Friday at 4:57 PM
As I mentioned in thenest discussion, asic resistance increases with the square of the number of functions, so X21R is more asic resistant than X16R, but both are pretty resistant
PlayHardLast Friday at 4:58 PM
Yeah more algos make it heavier on ASIC
DirkDiggler (Citadel Architect)Last Friday at 4:58 PM
My interpretation of the whitepaper was that we used x16r as it was brand new (thus ASIC resistant), and that was to ensure a fair launch... We've launched... I don't like the idea of constantly forking to avoid the inevitable ASICs.
x16r was a great "experiment" before we had any exchange listings... that ship has sailed though... not sure about all these x22rs lmnop changes
KAwARLast Friday at 5:00 PM
I believe that it is easier to change the direction of a bicycle than an oil tanker. We feel more like a train. We should lay out new tracks and test on them and find benefits that are acceptable to everyone except train robbers. Then open the new train station with no contentious feelings except a silently disgruntled minority group. ???
Hans_SchmidtLast Friday at 5:01 PM
The most productive action the community can do now re ASICs is to voice support for the devs to make a non-BIP9 change at a chosen block height if/when the need is clear. That removes the pressure to act rashly to avoid voting problems.
LSJI07 - MBITLast Friday at 5:01 PM
Thats why im proposing to fork at least once to a more asic resistant algo (but FPGA "friendly/possible"), with the proviso ideally that no more PoW algo forks are require to provide future ASICs some opportunity to innovate with silicon and efficiency.
TJayLast Friday at 5:01 PM
folks should take into account, that high end FPGAs like BCU1525 on x16r can't beat even previous gen GPUs (Pascal) in terms of hash cost. so they aren't a threat to miners community
PlayHardLast Friday at 5:02 PM
A proper change
Requires proper research
eyz (Silence)Last Friday at 5:02 PM
Just so I'm clear here, we are trying to boot ASICS, don't want CPUs because of Botnets, and are GPU and FPGA friendly right?
PlayHardLast Friday at 5:02 PM
It is not a quick one day process
eyz (Silence)Last Friday at 5:02 PM
If there is a bip9 vote there needs to be a clear explanation as I feel most in the community don't understand exactly what we are trying to fix
TronLast Friday at 5:03 PM
@Hans_Schmidt I like that route. It has some game theoretics. It gives time for miners to adapt. It is only used if needed. It reduces the likelihood of ASICs dominating the network, or even being built.
[Dev-Happy] BlondfrogsLast Friday at 5:03 PM
Hey guys. great convo. We are of course looking to do the best thing for the community and miner. We are going to be signing off here though.
justinjjaLast Friday at 5:03 PM
TJay that comes down to power cost.
If your paying 4c/kw gpus all the way.
But if your a home miner in europe an fpga is your only chance
LSJI07 - MBITLast Friday at 5:03 PM
@Hans_Schmidt How do we decide the block limit and when sufficient evidence is available? I would say we have had much compelling information to date...
[Dev-Happy] BlondfrogsLast Friday at 5:03 PM
Thanks for participating. and keep up the good work :smiley:
Have a good weekend.
CAWWWW
TronLast Friday at 5:03 PM
I haven't seen any compelling evidence of ASICs - yet.
Pho3nix Monk3yLast Friday at 5:03 PM
:v:
JerozLast Friday at 5:04 PM
I suggest to continue discussion in #development and #thenest :smiley:
thanks all!
TronLast Friday at 5:04 PM
Cheers everyone!
KAwARLast Friday at 5:04 PM
Agree with Hans.
DirkDiggler (Citadel Architect)Last Friday at 5:04 PM
thanks Tron
Pho3nix Monk3yLast Friday at 5:04 PM
Ending here. continue in Nest if wanted
DirkDiggler (Citadel Architect)Last Friday at 5:04 PM
I am waiting for compelling evidence myself.
submitted by mrderrik to Ravencoin [link] [comments]

Trying to get a deeper understanding of atomic swaps

Hi together,
I'm an IT-student and writing a thesis about atomic swaps on BTC and BTC-like blockchains. For the thesis I decided to use BTC, LTC, BCH and DCR. These chains have a somehow similar codebase and the same scripting language (I'm not a professional, so there might be differences, but they are not that serious). And they all have a high enough marketcap to be relevant for atomic swaps.
So the goal of the thesis is to find hashed timelock contracts (HTLCs) and connect matching HTLCs from different chains to get the atomic swap. Therefore I first searched the web for anything on atomic swaps [1] and analyzed the input script of this transaction [2] to get a basic understanding how atomic swaps work and what they look like.
Then I wrote a go program to search for any script longer than simple P2PKH scripts. This gave me a list of many different scripts which I analyzed by hand to only take the HTLC ones. (Besides many multisig scripts, there is not much to find on BTC^^)
At this point I found multiple different types of HTLCs as listed below. Afterwards I crawled* BTC again saving all transactions with HTLC scripts, storing the interesting data like tx-id, input value, pubKeyHashes, the secrets and their hashes. I found about one hundret HTLCs on BTC so far.
I did the same for LTC and found about 400 HTLCs.
As far as I understood, the secrets of HTLCs have to be the same on both chains. So I wrote another go program to match the found HTLCs from BTC and LTC and got around 30 matches. The next steps would then be to crawl BCH and DCR and also match the HTLCs found there.
* Crawling in this case means that I start to search the blockchain backwards (to get the newest first, the beginning years are not that interesting in this case^^) until the beginning of 2017. So about 18 months. As stated in [1] the first known atomic swap between BTC and LTC was made on 19th April 2017 (or April 19th 2017 or 19.4.2017 or whatever you like). So there is not much sense in crawling any further.
My questions now are the following:
I'm open to any constructive input and hope you have a few answers for me. Thank you in advance.
Type 1: sha256 secret, length=97byte
63 if 82 size 01 data1 20 88 equalverify a8 sha256 20 data32  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 2a: sha256 secret, length=94byte
63 if a8 sha256 20 data32  76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 68 endif 
Type 2b: sha256 secret, length=93byte
63 if a8 sha256 20 data32  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 3: ripemd160 secret, length=81byte
63 if a6 ripemd160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 4a: hash160 secret, length=86byte
63 if 03 data3  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify 82 size 01 data1 21 -> 33 88 equalverify a9 hash160 14 data20  87 equal 68 endif 
Type 4b: hash160 secret, length=82byte
63 if 03 data3  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify a9 hash160 14 data20  87 equal 68 endif 
Type 5a: hash160 secret, length=81byte
63 if a9 hash160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 04 data4  b2 checksequenceverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 5b: hash160 secret, length=78byte
63 if a9 hash160 14 data20  88 equalverify 76 dup a9 hash160 14 data20  67 else 01 data1  b2 checksequenceverify 75 drop 76 dup a9 hash160 14 data20  68 endif 88 equalverify ac checksig 
Type 6: hash160 secret, length=79byte
63 if 54  b1 checklocktimeverify 75 drop 76 dup a9 hash160 14 data20  88 equalverify ac checksig 67 else 76 dup a9 hash160 14 data20  88 equalverify ad checksigverify a9 hash160 14 data20  87 equal 68 endif 
Type 7: multiple ripemd160 secrets, length=80 + n*23byte
63 if a6 ripemd160 14 data20  88 equalverify a6 ripemd160 14 data20  ... 88 equalverify a6 ripemd160 14 data20  88 equalverify 21 data33  ac checksig 67 else 04 data4  b1 checklocktimeverify 75 drop 21 data33  ac checksig 68 endif 
Type 8: multiple ripemd160 secrets, length=81 + n*23byte
74 depth 60 16 87 equal 63 if a6 ripemd160 14 data20  88 equalverify a6 ripemd160 14 data20  ... 88 equalverify a6 ripemd160 14 data20  88 equalverify 21 data33  67 else 03 data3  b1 checklocktimeverify 75 drop 21 data33  68 endif ac checksig 
[1] http://www.cryptovibes.com/crypto-news/charlie-lees-atomic-swap-between-litecoin-and-bitcoin-was-a-success/
[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480
submitted by noobWithAComputer to Bitcoin [link] [comments]

Attention, benevolent BCH miners: A BCH segwit-recovery service is sorely needed!

These BCH are now recoverable; please read the update at the end of the post!

 
 

Background

In the short while since segwit activated on the BTC network and segwit addresses even-more-recently became the default for receiving BTC in the Trezor wallet - and perhaps other wallets too (soon?) - people have started accidentally sending their BCH to BTC-segwit addresses.
 
Due to the fact(s) that...
a) the BCH network supports P2SH (i.e. addresses starting with 3), but not segwit
... and ...
b) the sending wallets thus have no way of knowing that P2SH-wrapped segwit addresses really are "hiding" a segwit redeemscript
... people are losing access to their BCH, there's currently no way to prevent this, and it will continue happening.
 

Examples

(These are just the ones that I've noticed, but I'm sure there are many more that go straight to the various wallet service providers' support teams instead of via Reddit.)
 
To add insult to injury, the unlucky BCH owners are routinely told that there's no way to recover the coins (including by myself at the start) due to BCH not supporting segwit. And while that's currently true, it is ultimately only a half-truth.
After all, segwit opponents have often said that the satoshis in segwit addresses would be "anyone-can-spend" if the miners didn't enforce the segwit rules (i.e. ensuring that there's a proper witness/signature in the "segregated" part of the txs).
And on the BCH network the segwit rules aren't being enforced!
 

A Partial Solution

So I did some digging (e.g. in the segwit documentation and P2SH specification, BIP16) and came to the conclusion, which I'm sure that many have before me, that in order to spend money sent to a P2SH-wrapped segwit address, you only need to know the public key of the address (or more precisely: the RIPEMD160 hash of the SHA256 hash of a the public key).
Yes, a hash derived from the public key, not the private key.
Luckily, the 3-addresses don't by themselves reveal this public key hash, or anyone could've made "signed" txs from these "BCH-segwit" addresses - and someone probably already would have.
 

More Problems

So, given that it's relatively easy (for a technically inclined person, anyway) to get the public key corresponding to an address from their BIP39 mnemonic (aka wallet recovery seed), why aren't people re-claiming their BCH from these addresses?
Well, the "signature" that's needed isn't really a digital signature in the normal sense. Regular cryptocurrency transactions include a digital signature that doesn't reveal the private key that was used to make the signature in question. What's needed to "sign" for BCH-segwit addresses, however, is just literally including the public key hash that was mentioned above instead of a proper digital signature.
This means that anyone who sees such a transaction can just extract the public key hash from it - and then go on to create a conflicting transaction, using the same public key hash, that sends the same money elsewhere (to themselves, I would presume).
Technically, the second transaction would be a double-spend of the original and, as with all double-spends, it's the miners that would be the final arbiters of which transaction gets recorded in the block chain.
Additionally, a malicious miner could just create their own version of the transaction, either overtly redirecting the money to themselves, or covertly by changing the transaction to have no monetary outputs (i.e. all the money would go to the miner as "fee").
But the problems don't stop there. These segwit-spending transactions would be non-standard and as such wouldn't be relayed to the miners in the first place, nor would it be mined by miners even if it reached them (provided that the nodes and miners run with the default policy of ignoring non-standard txs, that is).
 

Suggested Solution

What we need is one or more trustworthy (yes, trust would unfortunately be required) miners to step up and make a BCH Segwit-Recovery Service for this particular purpose, in a somewhat similar way that they provided acceleration services for the BTC network (example1 and example2).
 
So... Does anyone know if a) miners are already working on this or b) know how to get in touch with them about this?
Or are there any benevolent miners here, that would like to:
 
/btc users, feel free to notify any miner contacts you may have - let's make this happen!
 
 

Update 1 (2017-09-11)

I made a proof-of-concept frontend to "show" what I'm envisioning such a service would look like for the end users (obviously it's ugly and needs to include javascript for key/hash/address validation, etc., but it should get the intention across), here:
https://btctroubadour.github.io/bch-recovery.html

Update 2 (2017-11-21)

It looks like some greyhat/vigilante, working with an unknown miner, was able to unilaterally claim some of the BCH that were "stuck" in BTC-segwit addresses (namely, the ones for which the public keys were revealed by the owners spending BTC from the same addresses), as explained in this post and comments: https://np.reddit.com/Bitcoin/comments/7eixcu/recovering_bch_sent_to_segwit_addresses/
For those that are affected by this, it means you no longer control your BCH (they were "stolen" by the greyhat), but he seems to be offering to give them back if you agree to letting him keep 30 % for his service (or "service", however you look at it). Either way, and given the alternative (100 % loss), you should certainly check if you're affected and decide how you want to proceed. As if that wasn't enough to deal with, there seems to be a ~2 week deadline, until "December 5th, 2017 at 23:59:59 UTC", after which it seems he's decided he's entitled to keep your money. :(

Update 3 (2017-11-28)

It looks like the greyhat has turned white! He's now offering to give back, for free, any and all BCH that were transferred to him (yes, 100 %!). Read his new update post and check if you were affected by this transfer.

Update 4 (2017-12-05)

Benevolent BCH miner finally found! The good people at btc.com have announced an automated BCH-segwit-recovery service, just as I outlined in my original post. Thanks a lot to Stellaluna19 for bringing it to my attention.
Here are links to btc.com's Twitter announcement as well as the recovery service itself:
https://twitter.com/btccom_official/status/933682190424199169
https://bch.btc.com/docs/help/bch_segwit_recovery
(Note that SatoshiLabs/Trezor developer, and well-known whitehat, -johoe have suggested some improvements to secure the process outlined by btc.com. You can read his suggestions in the last paragraph of this post - or in this one.)
submitted by btctroubadour to btc [link] [comments]

1st Round AMA Answers!

Based on the volume of questions from the East and West, we have compiled them all here. We also want to make sure the community has a chance to see all of the answers in a neat and orderly presentation.
 
Reddit 1st AMA Answers
What do you mean by “side chains”? Will the Hcash main chain run parallel with other chains, or are other chains plugged in based on certain block numbers? My question is based around the vertical and parallel scalability I see with EOS. What is the interaction with the side chains? Is this faster than vertical scaling?
Side chains will run parallel and be interoperable with the main chain. Side chains allow for new, more efficient, consensus mechanisms as well as smart contract functionality. Eventually other major blockchains will be interoperable with Hcash, through side chains and relays, DAG EVM for ETH, and other “Layer 2” solutions (Lightning Network for BTC and BTC forked code). Side chains allow for different scalability methods, flexibility and accessibility.
Is quantum resistance to protect against hacking, or against “fast mining” (preventing inequality between PoW miners)? How is it possible to guarantee quantum resistance? Isn’t our understanding of quantum computing just based on theories since quantum computers are not fully functional yet?
Quantum resistance is the protection against attacks made by quantum computers, which is currently contrasted by what we know about classical computers. Quantum computers weaken the security assumptions of certain types of cryptography, including ECDSA. If ECDSA were broken, attackers could steal balances in addresses that have made previous spends because the ECDSA public key for the address is revealed to the blockchain. Addresses with unexposed ECDSA keys will be resistant to this type of attack, as they are secured by RIPEMD160 and their ECDSA keys have not been revealed. Quantum resistance does not mean quantum proof. Quantum resistance means that quantum-based attacks do not have a significant advantage over the computers we have today. Based on what we currently know, our signature scheme is quantum resistant. No one knows what the future holds which is why it is important to always continue research and development into quantum resistant cryptography.
What do you mean by “exchange of value and valuable information”? Is this the exchange of coins and smart contracts?
The “value” you are referring is not derived from our current understanding of value (fiat). The “true value” that blockchain systems hold is stored in the hashes themselves. Data and information is king.
Imagine that in 2 years, a kid walks up to you and asks, “What do you do and how does it help society?”
We are one of many projects that helped build a more secure web of connected devices, and revolutionized peoples’ opinion on value and what really matters.
An uninformed businessman who has no understanding of blockchain, but has heard Bitcoin approaches you. How do you explain your product and the benefits to him so that he remembers to give you a call the next day?
Tell him to do his research on blockchain first before selling him on some grand idea. Smart investors grow a stable smart economy, not dumb money.
After reviewing the Hcash source code on GitHub https://github.com/HcashOrg/hcashd, I've found that almost all the Hcash main chain code has been written by SJTU (Shanghai Jiao Tong University), for example https://github.com/sammy00 https://github.com/yczhangsjtu. What have other contributors, such as the Nucleus Team, done for Hcash?
Shanghai Jiao Tong University’s Lab of Cryptography and Computer Security is the primary contributor to the main chain code. It is no small feat to have the 4th best university in China working on this project. The Nucleus Team is working with them to finish main chain testing. After the main chain launch, the Nucleus team will focus on the future development for Hcash including our side DAG EVM and main chain Lightning interoperability.
The main chain public repo hasn’t been updated very frequently.
Please refer to our new GitHub. The frequency of updates will increase as we approach/ pass the main chain launch.
When will the swap from Hshares to Hcash take place?
The swap to the main chain will take place after the main chain launch mid-February. Announcements will be made as to how and where you can swap your Hshares for Hcash.
What is the exact date of main chain launch?
The main chain launch will take place mid-February. We are aiming for release on February 15th.
Will you provide interoperability for all the existing blockchains?
We hope to provide interoperability for all blockchains in the future. That is a lot of work though. We will start with the larger chains that have healthy development and community sizes first. To make this easier, we plan to provide a back-end solution for new blockchains to make this process easier.
Will the interoperability between the blockchains support both transfer of data and transfer of value?
Yes
What is a block-less blockchain? Is this a traditional distributed system?
A block-less blockchain accomplishes the same goals as a traditional blockchain by using consensus to determine the order of transactions. A block-less blockchain, such as a DAG, allows for faster consensus without traditional block size requirements. Faster consensus means higher throughput.
How will Hcash bridge block-less and traditional blockchains?
Through relays between our main chain and side DAG. A more technical analysis will be available in our upcoming yellow paper.
What signature scheme will you use to achieve quantum resistance? Why?
Hcash is using the BLISS signature scheme. Hcash’s version of BLISS has been hardened to mitigate side channel attacks. BLISS was chosen for its efficient key and signature size.
Provide an overview as to how inoperability will be achieved.
We will be using relays to Hashed Timelock Contracts for Lightning Network interop on our main chain, relays and colored coins that operate with our DAG EVM, bridges to side chains for more uncommon chains, and back-end protocols for newer blockchains.
Specifically, what is the theory behind Hcash’s interoperability?
This answer would be longer than the entire AMA. Unfortunately, the specifics will have to wait until the yellow paper release. In the meantime, I would read the Lightning Network whitepaper because it is an excellent source of information. You could also research BTC relays and EVMs.
What is the timeline for interoperability? Will this be the main focus of Hcash? When can be expect an Alpha version?
We will be updating the roadmap in Q2. Interop timeframes will be easier to gauge after the main chain release. There are quite a few ideas around what we would like to tackle next, whether it would be assisting other projects on Lightning Network development, the DAG EVM implementation, or possibly both at the same time.
How will swap values be calculated when switching between blockchains? Is it based on the current market value?
Yes, it would be based on the current, real time market value.
Will you update the whitepaper to include a comprehensive overview of interoperability, its theory and its exchange functions?
In the coming months we plan to do an update on the white paper. The technical analysis will be provided in our yellow paper. These will be detailed in the updated roadmap to be released after the main chain launch.
Can you explain who will use the Hcash? I am trying to figure out where the supply and demand will come from.
Our target audience is everyone, from people playing mobile games to supporting business and government logic. The supply and demand will come with the need to transfer more and more data across multiple platforms. As for the economic model, this has not been outlined yet. We will be exploring all methods that fall in line with creating smart economies, including 2 token models.
Will you be hiring an advertising team?
We are already expanding Western marketing, primarily in the US. More focus on this will come soon after the main chain.
What are ring signatures in cryptography? How do they work?
At this time, we are exploring more efficient transaction schemes, such as bulletproofs. Bulletproofs can reduce the computational power needed for privatized/ anonymous transactions.
Most of us understand the interoperability of the network. What is a specific use case for Hcash? What role will Hcash have in the network? What makes it a requirement for interoperability? If someone has Bitcoin and wants to convert it to Ethereum using Hcash’s network wallet, is Hcash used as a fee for that conversion?
Here is an analogy. You walk into an arcade with 20 different machines. Each of these machines takes a different token, but you only have coins that operate with one of these machines. This would be the type of solution we hope to provide. Fees can be paid with Hcash. In the future we can explore taking fees in other denominations as well. More of this would be explained in detail with our yellow paper and economic model.
 
Baidu 1st AMA Answers
What specific date will the main chain go online?
Main chain release is mid-February, but we are aiming for launch on February 15th.
Are you willing to divulge how many apps you have in development for the Hcash main chain?
The primary focus right now is to improve the stability of the Hcash main chain. This will ensure successful launches in the future for developers on our side DAG EVM.
What is the Martian’s current relationship to Hcash? Is he still part of its team?
The Hcash team is currently located on Earth. The last I heard the Martian was returning to Mars.
Will the main chain go up according to schedule? Are there any problems with Hcash? The specialist sales team was made up of shareholders/ investors, right?
Provided no unforeseen circumstances, we are on schedule for the main chain release. There are roadblocks and disconnects with every project. This is a new world of technology we are exploring. I think the team you may be referring to is the Hcash Foundation themselves. A lot of the Western marketing and development is being handled by the Nucleus Team.
Is the code on GitHub all original? Are all developments executed on GitHub? Why is there so little original code? There are so few modifications. I also noticed there are remarkably few references to the code. Most of them are from documents that have been updated.
Many engineers have worked to contribute to the blockchain community over the years. We are taking advantage of the hard work and research that has been done while also making our own meaningful contributions for others to use in their code. It is important to acknowledge the contributions of others. The work completed by Decred in particular has allowed us to grow. Now we will have our chance to contribute back to them and others with our post quantum signature scheme and NG implementation. There are advantages of having similar projects that people don’t realize. For example, after our main chain launch we can explore assisting with development on the Lightning Network. As for GitHub, you will see activity increase when the main chain launches.
What is scope of the Hcash R&D team?
To assess, research and develop cutting edge decentralized consensus mechanisms and applications.
Hcash is currently collaborating with three universities. Shanghai Jiao Tong University has been working on the main chain quantum resistance. What are the main responsibilities of the other two universities?
Building blockchain technology is a group effort. The other teams have also been researching other options for main chains, smart contracts etc. For example, Dr. Joseph Liu from Monash University is working on ring signature schemes to continue our research and development into privatized transactions. We are looking forward to taking the best efforts of all teams and bringing them to the blockchain communities at large, starting with the post quantum implementation from LoCCS at Shanghai Jiao Tong University.
The Westerners working on Hcash don't seem very enthusiastic. They aren't following a lot of people on Twitter. Does the team have any clearer plans for increasing publicity?
The Westerners are primarily focused on the technology, development, and creating more content. The community management will be increasing transparency and activity in time. More Western marketing can be done after the launch of the main chain.
Are there plans to get onto more exchanges such as Bittrex?
When moon? We are constantly considering all options to allow users to access Hcash. Currently we are listed amongst some of the top exchanges like Binance and growing exchanges like KuCoin.
When will quantum resistant technology be implemented into Hcash? Where can we follow the developments being made and is there anywhere we can go to participate in the project?
Quantum resistant technology is available now on GitHub at https://github.com/HcashOrg/hcashd and will be available for use outside of the testing environment when the main chain launches in the middle of February.
Where do you download the wallet? How do you mine?
The wallet for the new main chain can be found on GitHub at https://github.com/HcashOrg/hcashwallet. You can mine on the new main chain by joining a pool or using the hcashd node to solo-mine.
When will Hshares swap Hcash? Can you announce a general time?
Hshares can be redeemed for Hcash after the main chain launches in the middle of February. Announcements will be made regarding how and where to swap your Hshares for Hcash.
Will there be an address mapping when Hshares swaps to Hcash like there was with EOS? What other kind of mechanism will be used for the coin swap?
A snapshot of Hshares will be included in the Genesis (first) block of Hcash’s launch to allow users to convert their Hshares into Hcash. An announcement will be made as to how, when and where conversions will take place.
When will the main chain that can support smart contracts go online? When will tokenization for Hcash take place?
Smart contract functionality will be available when our side DAG launches. Users, businesses and developers will be able to build dApps, launch tokens and more. We are making sure the main chain is a stable foundation before adding our DAG to the Hcash ecosystem.
There aren't many updates on GitHub and there aren’t many contributors. What kind of coordination is going on with the development team?
Both the Nucleus Team and members of Shanghai Jiao Tong University LoCCS are working together to finalize testing. Updates are being made to our GitHub at https://github.com/HcashOrg/hcashd.
Based on what I've been reading, Shanghai Jiao Tong University is mainly responsible for the main chain portion of the project. How is their team doing? How many research students in their labs are helping them?
Shanghai Jiao Tong is responsible for building and launching the new main chain. Their team there has been doing a great job with research and development and we look forward to seeing more of their work. The Nucleus Team is currently working with them to finish testing. After testing, the Nucleus team will focus on the future development of the project including our side DAG. I do not know the size of their team as we have not visited their lab.
Can you confirm that the main chain will finally go up in mid-February? Is it just a hypothetical date and then a further delay?
The primary responsibility is to make sure the main chain is stable and secure so that it can be used as the foundation to add other important features to the Hcash ecosystem, like smart contracts and hidden transactions. Everyone is working very hard to hit the target release date of mid-February. We are planning on mid-February for the launch unless anything unexpected comes up.
What is the status of these interoperability features? When is the main chain going online?
Main chain will be released mid-February. The interoperability features depend on the stability of the network. Our side DAG EVM will be the quickest addition to the Hcash ecosystem that will allow for ETH interoperability. Lightning Network on the main chain will require further research and development.
Won’t zero knowledge proofs conflict with the system’s throughput?
We are currently working on more uncommon implementations of zero proof knowledge, such as bulletproofs that allow for efficient transaction speeds. We can also achieve higher throughput with our side DAG.
 
Thank you to everyone who participated! Round 2 of our AMA session leading up to the launch of the main chain will be announced shortly 😊
submitted by Mr_Handsome_Nucleus to hcash [link] [comments]

17.956 Hacked Brainwallet Passwords

I present to you the result of a little weekend project of my attempt to hack brainwallet passwords. Please note that I didn't steal anybodies money. I've done this just because I was curious.
My program works like this:
  1. Calculate the RIPEMD160 for large password lists and stores them as key-value pairs in a database (RIPEMD160 -> password). I've used leveldb for this.
  2. With a blockchain parser I parse the blockchain and extract all the RIPEMD160 hashes of each bitcoin address.
  3. Then I just make a lookup of each hash in the database, and if I find an entry, I've cracked a brainwallet.
  4. As an additional step, it would be easy to just monitor the blockchain and each time a new transaction arrives, lookup the addresses in the database and extract the money if there is a match (I'm not doing this...)
Here are some things I've learned that I'd like to share:
Most important lesson:
submitted by martinus to Bitcoin [link] [comments]

Namechains

Namechain Domain Example
Generate a private key from UTF-8('namechain') = 6E 61 6D 65 63 68 61 69 6E (with a bunch of leading zeros to be accurate).
Generate the pubkey: secp256k1(6E 61 6D 65 63 68 61 69 6E)
Generate an actually secure private key.
Generate a pubkey from that.
Create a 2 of 2 multisig address from those two pubkeys. I should note here that for generic TLD names, ideally we wouldn't require a second key and a multisig address, only the first keypair composed of the 'name' keys. The reason I have the second keypair in this iteration is because I'm not proficient enough with P2SH 'redeem scripts' to know how to write a script that guarantees funds flowing through an address without someone being able to sniff node traffic and try and double spend those funds as they 'flow through' (or if that script is possible but I'm fairly certain it is?). This would be pretty useful. As for now, it's just extra data (so extra costs), but it does allow for a 'name' to sign names under it similar to a CA scheme, effectively creating two chains from a name: a signed one and an unsigned one. Maybe this is desirable.
Anyways, fund that multisig address. Spend those funds to an 'ownership' address to expose the public keys (used for verifying names/values with keys). This conveniently lets us establish an ownership address though, whose address itself can be used as the corresponding key to our name that allows us to generate signatures to verify ownership (and can be used later for transferring).
So now a name and key are paired together. If someone signs a message saying they are 'namechain', we can verify this by searching through transactions, attempting to find a public key that matches that name by searching for the first 'place-in-chain' transaction with a signature whose public key matches secp256k1(UTF-8('namechain')) and verify the signature from the ownership address one transaction away (we can use the ownership address to devise a protocol for transferring names too). Even though it's a multisig transaction, each key is exposed individually, so the convention is the 'name' key is always first or something.
Problems:
This method makes names a function of transactions (which miners will like), makes names hard to prune? (if you care about them), effectively putting trust into the blockchain rather than a third party. Names are still discoverable in the sense that you can create a list of names and scan the blockchain for them. As far as how names are domains, consider that namechain is a part of the bitcoin domain. Registering an unsigned name under the namechain domain might involve creating a multisig transaction that includes 'namechain''s keys, your new name's keys, and for now, that pair of secure keys that ensures you don't get robbed while registering. For signed names, that 2 of 2 multisig address you used to register it would act as the signing address similar to a CA scheme. This means we can go as deep as bitcoin allows addresses in a P2SH multisig 'address' (i think 15 or 20, and probably infinite eventually, the current limit is only enforced by the client?). Possible uses for business people: A service that allows users to register a name, and that offers up an API for verifying names and signatures for websites, effectively creating a universal login (because anyone can do it themselves too!). Or a CA service like I mentioned before. Maybe a certain company is developing a compact node you can use at home to verify this kind of stuff and ultimately act as a sort of 1/2FA for pretty much anything. You could do hostname resolution from it by creating a second private key equivalent to an IPv4 or IPv6 address to match with a name and signature. Orphaned blocks are really only a problem if two people register one name in two different valid blocks at the same time, so pretty damn unlikely. There a ton of places to optimize this, but the point is it allows me to associate a name or value with a public key.
Miners could choose to ignore blocks of a name-registration structure without additional fees. Solving the name 'lottery' scenario by using bitcoin Script to allow for registration based on the previously registered name and/or block and necessitating anyone registering a name to create identical transactions would turn the lottery into a 'bid war' per block. Might not be possible. Haven't been looking at the protocol for too long. Tear it to shreds please. Looking into building a proof of concept.
submitted by ftlio to Bitcoin [link] [comments]

BIP Number Request: Open Asset | Nicolas Dorier | May 26 2016

Nicolas Dorier on May 26 2016:
Open Asset is a simple and well known colored coin protocol made by Flavien
Charlon, which has been around for more than two years ago.
Open Asset is OP_RETURN to store coin's color. Since then, the only
modification to the protocol has been for allowing OA data to be into any
push into an OP_RETURN.
The protocol is here:
https://github.com/OpenAssets/open-assets-protocol/blob/mastespecification.mediawiki
I asked to Flavien Charlon if he was OK if I submit the protocol to the
mailing list before posting.
Additional BIP number might be required to cover for example the "colored
address" format:
https://github.com/OpenAssets/open-assets-protocol/blob/masteaddress-format.mediawiki
But I will do it in a separate request.
Here is the core of the Open Asset specification:
Title: Open Assets Protocol (OAP/1.0)
Author: Flavien Charlon
Created: 2013-12-12
==Abstract==
This document describes a protocol used for storing and transferring
custom, non-native assets on the Blockchain. Assets are represented by
tokens called colored coins.
An issuer would first issue colored coins and associate them with a
formal or informal promise that he will redeem the coins according to
terms he has defined. Colored coins can then be transferred using
transactions that preserve the quantity of every asset.
==Motivation==
In the current Bitcoin implementation, outputs represent a quantity of
Bitcoin, secured by an output script. With the Open Assets Protocol,
outputs can encapsulate a quantity of a user-defined asset on top of
that Bitcoin amount.
There are many applications:
could then be traded frictionlessly through the Bitcoin
infrastructure.
could withdraw and deposit money in colored coins, and trade those, or
use them to pay for goods and services. The Blockchain becomes a
system allowing to transact not only in Bitcoin, but in any currency.
of colored coins. The door would only open when presented with a
wallet containing that specific coin.
==Protocol Overview==
Outputs using the Open Assets Protocol to store an asset have two new
characteristics:
asset stored on the output.
many units of that asset are stored on the output.
This document describes how the asset ID and asset quantity of an
output are calculated.
Each output in the Blockchain can be either colored or uncolored:
both undefined).
non-null asset ID.
The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the
output script referenced by the first input of the transaction that
initially issued that asset (script_hash =
RIPEMD160(SHA256(script))). An issuer can reissue more of an
already existing asset as long as they retain the private key for that
asset ID. Assets on two different outputs can only be mixed together
if they have the same asset ID.
Like addresses, asset IDs can be represented in base 58. They must use
version byte 23 (115 in TestNet3) when represented in base 58. The
base 58 representation of an asset ID therefore starts with the
character 'A' in MainNet.
The process to generate an asset ID and the matching private key is
described in the following example:

The issuer first generates a private key:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725.

He calculates the corresponding address:

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM.

Next, he builds the Pay-to-PubKey-Hash script associated to that

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY
OP_CHECKSIG.

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

Finally, the hash is converted to a base 58 string with checksum

using version byte 23:
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC.
The private key from the first step is required to issue assets
identified by the asset ID
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. This acts as a
digital signature, and gives the guarantee that nobody else but the
original issuer is able to issue assets identified by this specific
asset ID.
==Open Assets Transactions==
Transactions relevant to the Open Assets Protocol must have a special
output called the marker output. This allows clients to recognize such
transactions. Open Assets transactions can be used to issue new
assets, or transfer ownership of assets.
Transactions that are not recognized as an Open Assets transaction are
considered as having all their outputs uncolored.
===Marker output===
The marker output can have a zero or non-zero value. The marker output
starts with the OP_RETURN opcode, and can be followed by any sequence
of opcodes, but it must contain a PUSHDATA opcode containing a
parsable Open Assets marker payload. If multiple parsable PUSHDATA
opcodes exist in the same output, the first one is used, and the other
ones are ignored.
If multiple valid marker outputs exist in the same transaction, the
first one is used and the other ones are considered as regular
outputs. If no valid marker output exists in the transaction, all
outputs are considered uncolored.
The payload as defined by the Open Assets protocol has the following format:
{|
! Field !! Description !! Size
|-
! OAP Marker || A tag indicating that this transaction is an
Open Assets transaction. It is always 0x4f41. || 2 bytes
|-
! Version number || The major revision number of the Open Assets
Protocol. For this version, it is 1 (0x0100). || 2 bytes
|-
! Asset quantity count || A
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] representing the number of items in the asset
quantity list field. || 1-9 bytes
|-
! Asset quantity list || A list of zero or more
[http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
|-
! Metadata length || The
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] encoded length of the metadata field. || 1-9
bytes
|-
! Metadata || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
|}
Possible formats for the metadata field are outside of
scope of this protocol, and may be described in separate protocol
specifications building on top of this one.
The asset quantity list field is used to determine the
asset quantity of each output. Each integer is encoded using variable
length [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also
used in [https://developers.google.com/protocol-buffers/docs/encoding#varints
Google Protocol Buffers]). If the LEB128-encoded asset quantity of any
output exceeds 9 bytes, the marker output is deemed invalid. The
maximum valid asset quantity for an output is 263 - 1
units.
If the marker output is malformed, it is considered non-parsable.
Coinbase transactions and transactions with zero inputs cannot have a
valid marker output, even if it would be otherwise considered valid.
If there are less items in the asset quantity list than
the number of colorable outputs (all the outputs except the marker
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the asset quantity list than the
number of colorable outputs, the marker output is deemed invalid. The
marker output is always uncolored.
After the asset quantity list has been used to assign an
asset quantity to every output, asset IDs are assigned to outputs.
Outputs before the marker output are used for asset issuance, and
outputs after the marker output are used for asset transfer.
====Example====
This example illustrates how a marker output is decoded. Assuming the
marker output is output 1:
Data in the marker output Description ----------------------------- 
0x6a The OP_RETURN opcode. 0x10 The PUSHDATA opcode for a 16 bytes payload. 0x4f 0x41 The Open Assets Protocol tag. 0x01 0x00 Version 1 of the protocol. 0x03 There are 3 items in the asset quantity list. 0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list: - '0xac 0x02' means output 0 has an 
asset quantity of 300.
 - Output 1 is skipped and has an 
asset quantity of 0
 because it is the marker output. - '0x00' means output 2 has an 
asset quantity of 0.
 - '0xe5 0x8e 0x26' means output 3 
has an asset quantity of 624,485.
 - Outputs after output 3 (if any) 
have an asset quantity of 0.
0x04 The metadata is 4 bytes long. 0x12 0x34 0x56 0x78 Some arbitrary metadata. 
===Asset issuance outputs===
All the outputs before the marker output are used for asset issuance.
All outputs preceding the marker output and with a non-zero asset ...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012741.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Requirement for pseudonymous BIP submissions | Chris Stewart | Mar 18 2017

Chris Stewart on Mar 18 2017:
As everyone in the Bitcoin space knows, there is a massive scaling debate
going on. One side wants to increase the block size via segwit, while the
other side wants to increase via hard fork. I have strong opinions on the
topic but I won’t discuss them here. The point of the matter is we are
seeing the politicization of protocol level changes. The critiques of these
changes are slowly moving towards critiques based on who is submitting the
BIP -- not what it actually contains. This is the worst thing that can
happen in a meritocracy.
Avoiding politicization of technical changes in the future
I like what Tom Elvis Judor did when he submitted his MimbleWimble white
paper to the technical community. He submitted it under a pseudonym, over
TOR, onto a public IRC channel. No ego involved — only an extremely
promising paper. Tom (and Satoshi) both understood that it is only a matter
of time before who they are impedes technical progress of their system.
I propose we move to a pseudonymous BIP system where it is required for the
author submit the BIP under a pseudonym. For instance, the format could be
something like this:
BIP: 1337
Author: 9458b7f9f76131f18823d73770e069d55beb271b at protonmail.com
BIP content down here
The hash “6f3…9cd0” is just my github username, christewart, concatenated
with some entropy, in this case these bytes:
639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b
and then hashed with RIPEMD160. I checked this morning that protonmail can
support RIPEMD160 hashes as email addresses. Unfortunately it appears it
cannot support SHA256 hashes.
There is inconvenience added here. You need to make a new email address,
you need to make a new github account to submit the BIP. I think it is
worth the cost -- but am interested in what others think about this. I
don't think people submitting patches to a BIP should be required to submit
under a pseudonym -- only the primary author. This means only one person
has to create the pseudonym. From a quick look at the BIPs list it looks
like the most BIPs submitted by one person is ~10. This means they would
have had to create 10 pseudonyms over 8 years -- I think this is
reasonable.
What does this give us?
This gives us a way to avoid politicization of BIPs. This means a BIP can
be proposed and examined based on it’s technical merits. This levels the
playing field — making the BIP process even more meritocratic than it
already is.
If you want to claim credit for your BIP after it is accepted, you can
reveal the preimage of the author hash to prove that you were the original
author of the BIP. I would need to reveal my github username and
“639c28f610edcaf265b47b0679986d10af3360072b56f9b0b085ffbb4d4f440b”
The Future
Politicization of bitcoin is only going to grow in the future. We need to
make sure we maintain principled money instead devolving to a system where
our money is based on a democratic vote — or the votes of a select few
elites. We need to vet claims by “authority figures” whether it is Jihan
Wu, Adam Back, Roger Ver, or Greg Maxwell. I assure you they are human —
and prone to mistakes — just like the rest of us. This seems like a simple
way to level the playing field.
Thoughts?
-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170318/c788f5e3/attachment.html
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013735.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

[uncensored-r/BitcoinMarkets] Bitcoin Tech Rant - Happy New Year: Atomic Cross Chain Swaps

The following post by L14dy is being replicated because some comments within the post(but not the post itself) have been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ BitcoinMarkets/comments/7n5dwi
The original post's content was as follows:
Hola,
I didnt have much success with the last Tech Rant, so I decided to do another. Please provide feedback.
So the topic for this tech rant is Cross Chain Swaps. They’re pretty simple, but require a bit of understanding of Bitcoin Script. I will start off with on-chain swaps.
So, let’s assume I want to swap testnet BTC for mainnet BTC with you (for instance if someone wants millions of testnet coins and is willing to pay 0.01 BTC for them). How would you be able to pay me and ensure that you actually get the testnet coins? Well, the easiest way is for us to agree that u/jaderadej will be our escrow. We both trust him, so we he generates an address and provides this address to the both of us. We then each generate a new address and provide it to u/jaderadej. At this point we both send our coins to the address he generated. One tx on testnet and the other on mainnet. As soon as u/jaderadej receives the coins from both of us, he does the swap (minus his “fee”). If I send coins but you dont, then he sends them back to me. If you send coins but I dont, then he sends them back to you.
Now, this works fine as long as we both trust u/jaderadej, and we do, but what if the only person willing to do it is u/pineconecandle. Well, I dont trust u/pineconecandle ;), so why would I do this deal? I wouldn’t. Hence, we need to do it without a third party. And this is possible in Bitcoin.
The first thing you need to understand is how OP_IF works. Basically OP_IF allows you to create a conditional branch of your PubKey Script. The second thing you need to udnerstand is how OP_CLTV works: OP_CLTV stands for Check Lock-Time Verify. It is an OP_Code that accepts an integer as input, which is either interpreted as a unix timestamp or as a block number (there is a convention on when the integer is interpreted as which, you can google it if you care). So now we can create a PubKey Script on a UTXO that has one PubKeyScript branch OP_IF OP_CLTV {Script1} OP_ELSE {Script2}
Ok, so enough with the preliminaries. On to the actual protocol.
I have testnet coins and you want to buy them. So what you do is you generate a random byte string (some random sequence of bits with enough entropy to ensure I cant brute force it before the lock-time we agree upon is up. If you use a cryptographically strong random number generator that will be fine. You generate this random number and hash it, i.e. OP_SHA256 or OP_RIPEMD160, whichever of the two is fine. Usually you would SHA.
I generate an address and provide you with the hash of my public key.
You then also generate a new address and send both the hash and the new hash of the public key to me. You now spend you 0.01 BTC to an output with a PubKey Script like the one above where Script 1 is just a normal P2PKH for your new address and Script 2 is a simple pre-image check combined with a P2PKH for my address, i.e. first hash the first element in the SigScript, compare that it matches the commitment value for the hash and finally check the standard P2PKH Script, i.e. soemthing like
{Script1}: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
{Script2}: OP_SHA256 OP_EQUALVERIFY OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Now, eventually I will see this transaction show up on the mainnet blockchain. Since you are the one looking to buy from me, you pony up the cash. Now, if I change my mind and walk away your coins are not gone. Once the lock-time is up, you can just use you knowledge of the private key to your address to create a SigScript that satisfies Script 1 above. So far no trust needed... you will NOT lose your coins.
Ok, but I want to sell my testnet coins, so I decide to Pony up the testnet coins. I spend them to an output with the same PubKeyScript, only that I reverse the roles of our public key hashes AND more importantly, I cut the lock-time in half. Since you have the hash, I want to make sure I get my coins back before you can take your BTC back, otherwise you could take both.
So now I spend to that and you see it show up on the testnet blockchain. If you decide to walk away, thats fine. I can just get my testnet coins back in half the time you can. Again, no trust needed. Why? Well, even though you know the secret random number, since you dont control the private key associated to my address, you wont be able to satisfy the pubKey Script to take your BTC back and you cant take my testnet coins without revealing the secret random number in the SigScript of the spending transaction. Since all SigScripts are public information, you cant spend my testnet coins if you want to keep the random number secret.
Let’s assume we went through all this hassle to actually do the deal. So, now you spend the testnet coins to a new address that you control (P2PKH) by revealing the random number and providing a SigScript for the address you control in the OP_ELSE branch of the PubKeyScript.
As soon as you do that, I see the random number, and I can now spend your 0.01 BTC to an address I control using the Secret Random Number You revealed to me, along with the SigScript for the P2PKH of the address I control.
And voila. We just exchanges testnet BTC for mainnet BTC in a trustless fashion with no trusted third party using some pretty simple Cryptographic primitives. Done deal.
Now, notice a few things:
  1. You need to wait a bunch of confs before this can be done, because you want to avoid double spending of your counterparty (whom you do not trust)
  2. Tetsnet is kinda a stupid example, because its pretty easy to reorg the chain. I just didn’t wanna mention another coin.
  3. In Lightning this can be done instantly. No need to wait for confs and no need to wait too long for lock-times to expire. Basically it is achieved by routing the payment to yourself on the Lightning Network. You can also combine on-chain swaps with off-chain swaps. Pretty cool stuff. This is basically how decentralized exchanges would work on Lightning.
Ok, done. Hope you like it!
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

2 humble proposals for Litecoin's proposition

One of the key aspects of success on the web is the proposition. I'm into Litecoin because it has a great proposition (zero pre-mining, stronger crypto for mining, 2m30s block, etc). Let me just give you one example of a failed proposition just so everyone knows where I'm coming from.
Failed proposition Microsoft once had its encyclopedia, Encarta. But MS saw the writing on the wall: wikipedia and user-generated content would kill them. So at one point, they "opened" Encarta for people to edit. Unfortunately, if you clicked edit, unlike wikipedia, you were first led to a page full of legalese telling you that you were about to transfer your intellectual property rights to Microsoft Corporation, etc. As people saw that, they basically went FU and didn't bother improving Encarta. These days, you can read about Encarta on wikipedia, ironically.
Proposition is extremely important, and it's mostly psychological. The best book about it is "Here comes everybody".
I have been thinking a lot about this, and I think it would be productive for all of our community if we were to discuss how can we subtly improve Litecoin without alterations to code (i.e., no risks). What I mean are minor tweaks in the perception and the proposition of Litecoin.
So I would like to throw some ideas out there:
Idea #1. 256-bit standard address: instead of reducing the SHA256 to RIPEMD160, and creating even the (minute) probability of collusion, we should think about having more security than Bitcoin and use RIPEMD256. The core of the system doesn't even have the idea of "address", so this could be done, correct me if I'm wrong, easily--zero risk. There might opposition to this, as it increases our blockchain size, by 92bits per new, changed, address. Yet, I would love to be able to brag about Litecoin's stronger crypto in addresses and in mining. Scrypt is way better than SHA2 and Litecoin is already more secure than bitcoin (architecturally, not in hashing power, due to the influx of ASICs). But we may also want to differentiate by having stronger, harder to break addresses.
Idea #2. The "unit" (or "Schelling point"). In bitcoin, there are two clear "units": one bitcoin and one satoshi. But 1 bitcoin = 100 million satoshis makes for unnatural calculations and some cognitive overload (see, for instance, this card experiment, or this simple cognitive reflection task, or the hard Monty hall problem). These situations and experiments show that people have a hard time (cognitively) dealing with even simple problems. I think we can do better if we use what's on already people's minds: cents, and create/name the "Lite", with 1 Litecoin = 1,000,000 Lites (with 1 Lite being 100 Lite-cents).
As a silly example, it is smoother and easier to tell friends "Just paid 2 bucks on a million Lites" than "Just paid 200 bucks on a bitcoin". The words million and billion are associated with wealth, in a way that "coin" isn't. "You have 56 million lites?" sounds and feels better than "you have 56 litecoin?" I'm not talking about dropping the name litecoin (it's awesome), but about naming the quote-"smallest unit"-endquote as something that makes for immediate calculation (and of course the real "smallest unit" would be a cent of a "Lite").
I'm sorry for the wall of text. But I think we can improve Litecoin's proposition, and that if we do so, we'll have an even bigger lead against the other cryptocurrencies out there. From Zimbabwe dollars to gold, money is about trust and confidence. Let's be cryptographically stronger than anyone out there, and let's let those who join us make immediate, natural, system 1 calculations.
Again, I'm sorry for the wall of text, I thank you for reading this far, and may Litecoin have a long prosperous life!
submitted by asymmetric_bet to litecoin [link] [comments]

How miners can support an alternative to the fee market

I've submitted a proposal and would like to get more feedback and support.
The non-technical details:
The fee market is meant to be a way for transaction senders to give up something in exchange for priority processing. Unfortunately because of network congestion, the fees have spiraled out of control.
I have outlined a method for transaction senders to use Proof-of-Work encoded in an OP_RETURN output as a replacement for miner fees. The more work they do, the higher the priority of the transaction.
It won't solve the backlog, but it'll stop the excessive fees for participating transaction senders.
This will require a significant portion of miners to support the concept. If all the miners signaling for a block increase support the policy and run the code, this will work.
Some answers for expected questions or comments
How will we get enough support for it to activate? Since it's just a new mempool prioritization policy, there is no need for any kind of majority of hashpower to support it.
What if it forks the network? There are no risks of forks. This is just mempool prioritization policies for miners.
What clients will be able to create the TxPoW proofs? None yet, obviously, but all the hashing is pretty simple and the methods are already in Bitcoin (SHA256 and RIPEMD160). It would be pretty easy for node implementations or scripts or wallets to add the functionality. Ideally, wallets or nodes will be able to be configured to find the best proof in a certain amount of time (i.e. find the best PoW you can find in 5 seconds)
What about Blockchain bloat? Since the data is stored in OP_RETURN, it can be pruned from block storage.
How can this help with the biggest problem, which is the lack of on-chain scaling? Since it'll allow the "economic majority" to use CPU power to prioritize their transactions on EC supporting miners, they won't signal for USAF because it would force them to use the fee market again. Core also has a problem with "not invented here" syndrome. If it appears in BU/Classic/bcoin/btcsuite first, it'll likely never make it into Core. It'll help illustrate that other than the sep256k speed improvements, Core hasn't really accomplished much of note in the last few years while other implementations are innovating in ways to help Bitcoin and the business community around it thrive.
What would Satoshi think? I think he would like this idea. He embraced PoW as a way for parties to stake an economic interest, and PoW can be used as a way to prove an economic interest in a transaction just as much as miners fees prove.
Why would miners go along with this when they can make so much in transaction fees? Miners are selfish (they're supposed to be), but that doesn't specifically mean that they want to make a load of money in fees. TxPoW transactions will have fees (required to make sure they aren't filtered out on the P2P layer), but they can be the fees we saw a year or two ago. I postulate that miners will see that low transaction fees are better in the long term for the health of the network and will see this as being in their best interest.
What will this enable and why is this good for Bitcoin? If you have a wallet full of dust UTXO's, you can use a lot of CPU power in order to craft a transaction that'll allow you to consolidate them. Micropayments can come back again too.
submitted by DeftNerd to btc [link] [comments]

BITCOIN COULD SUDDENLY DUMP TO THIS PRICE DUE TO THIS RARE PATTERN (btc market prediction news today Bitcoin Rising With The Tide?! July 2020 Price Prediction & News Analysis Hack Bitcoin Wallet 2019/2020 (CryptoKeys) Cracking Wallets [Fast Download] The US Just Made THE LARGEST PURCHASE of Bitcoin Miners in History! Cryptocurrency News Online 2020 WOW!!! MOST BULLISH BITCOIN NEWS OF 2020!?! REAL OR FAKE???

In theory there's no limit to how much a bitcoin can be divided. Currently 0.00000001BTC is the smallest amount possible. But if there's only 0.00001 bitcoins left in the world then the program can be easily updated to allow 0.00000000000000000001BTC to be sent and used. Crypto. ripemd160 (buffer) // <Buffer 5f 95 6a 88 86 30 51 ea 52 15 d8 97 0c ed 8e 21 8e b6 15 cf> hash256 Utility for creating double sha256 hash digests of data Bitcoin History is a multipart series from news.Bitcoin.com charting pivotal moments in the evolution of the world’s first cryptocurrency. Read part 16 here . Images courtesy of Shutterstock. The informant also calculates the RIPEMD160 hash of the secret and publishes it: this is hashed_secret, which is a (public) Bitcoin address. This two-hash process is the standard algorithm by which Bitcoin calculates public addresses from private keys [1]. VeraCrypt, free disk encryption software bought from IDRIX, is now accepting Bitcoin donations.Based on TrueCrypt, VeraCrypt adds enhanced security to the algorithms used for system and partition encryption, which supposedly makes it immune to new developments in brute-force attacks.

[index] [20602] [6584] [31014] [6024] [17014] [17116] [5884] [11896] [10787] [2340]

BITCOIN COULD SUDDENLY DUMP TO THIS PRICE DUE TO THIS RARE PATTERN (btc market prediction news today

07:20 Ethereum News 08:24 Huobi Bitcoin News 09:51 Final Thoughts ***** Support the channel:--Buy Bitcoin w/ the Cash App! The easiest way to buy bitcoin in 2020 in the US! Try using my code and ... The BTC news & analysis can be inspiration for your own Bitcoin trading or investing, but is NOT financial advice. On this channel, The Moon, I make 1 video every single day about crypto news ... BITCOIN TODAY: Bitcoin is getting an ETP by a German company. In this video, I'll go through the Bitcoin news today & I'll make a Bitcoin price analysis. The BTC news & analysis can be inspiration ... BITCOIN SETUP FOR HUUUGE BULL RALLY?!! 💰Crypto Analysis TA Today & BTC Cryptocurrency Price News Now - Duration: 13:38. Crypto Kirby Trading 13,976 views 13:38 For daily updates on cryptocurrency and the best bitcoin news online , hit the bell, like and subscribe! ****This is a Sponsored Video***** Altcoin Daily and CryptoTraderTax have entered into an ...

Flag Counter