Bitcoin Forum
August 19, 2019, 07:31:55 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 »
1  Bitcoin / Development & Technical Discussion / Armadillo in RSK: placing merge-mining security on par with Bitcoin mining on: August 01, 2019, 10:00:01 PM
Recently RSK (the first merge-mined Bitcoin sidechain) hard-forked to add a feature to increase the security of merge-mining. The new security protection, called Armadillo, is quite simple to understand.

The idea is to add to the RSK merge-mining tags additional information that enable the reconstruction of the RSK fork graph even if the actual RSK blocks are hidden from the RSK network.

Then, any node can monitor the Bitcoin blockchain and, in case of detecting a malicious hidden fork, emit alerts that flood the RSK network. These alerts are decentralized and Sybil-attack protected. Nodes can choose to enter a temporary "Safe Safe Mode" (to differentiate it from Bitcoin's old Safe Mode Smiley). In this mode they do not confirm transactions, so high-stake economic nodes, such as Exchanges, won't accept deposits.

I wrote an article about how it works and the security it brings here:

https://bitslog.com/2019/08/01/armadillo-more-consensus-security-for-rsk/

Happy to receive feedback and hear other ideas.

2  Bitcoin / Development & Technical Discussion / DagCoin: a cryptocurrency without blocks on: September 11, 2015, 11:10:14 PM
DagCoin: a cryptocurrency without blocks

Back in 2012 I thought a lot on a new cryptocurrency that could merge the concepts of transaction and block. Each transaction would carry a proof-of-work and reference one or more previous transactions. The resulting authenticated data structure would be a Direct Acyclic Graph (DAG) of transactions where each transaction “confirms” one or more previous transactions. The confirmation security of a transaction would be measured in accumulated amount of proof-of-work referencing (or confirming) the transaction. This structure is well suited for a cryptocurrency without subsidy (such as a side-chain). On the past years I’ve read a couple of similar proposals on bitcointalk (although I cannot find the references now). When the GHOST paper was published, I perceived it as a reinforcement of my idea that a tree could give more security than a chain in case of high rate of transactions.

My open problems…

The problem that I could not solve in 2012 is how to limit the maximum cut of the generated DAG or, in other words, how to prevent all new transactions from referencing the same set of parent transactions. How to create the incentive to “move forward”? The DAG must not increase in “width”, and it should look more like a DAG-chain. Also one must prevent users from choosing old transactions to extend the DAG. I tried several monetary incentive structures to force users to choose newer transactions, but with no result. To know the last “ledger state” there must be a way to consolidate branches. Merging branches should be good, but not too good such that everyone starts merging the same branches over and over. The problem of spam was also less important, as no transaction would be able to get a “free ride” in a block, as each transaction carries PoW. Ultimately the owners of a computer that is being part of a spamming botnet would realize their computers have been hijacked based on the amount of CPU consumed. For instance, if a transaction requires a proof-of-work that takes 1 second in a standard PC, and each transaction is 400 bytes in size, then a botnet consisting in 10K computers may create transaction reaching 3 Mbytes/second. This high network bandwidth usage itself is not a problem, since it can disrupt the network only as long as the attack is active. However, there must be a way to prevent the DAG-chain from growing at that pace. It turns out that the election of an optimal data structure allows the DAG-chain to be compressed, but it requires us to change how we think about double-spends, and how we conceive the “ledger state”.

A Radical Change

The leap of faith required to find an out-of-the-box solution is to think about double-spends not as a boolean attribute, but as a probabilistic attribute, based on comparing the confirmation work on competing transactions. An the security of a transaction, as the confirmation work compared to the the work expected that an adversary may use. Also it requires to forget about the concept of a “global ledger state”. In Bitcoin there is a global ledger state. Chain reorganizations can always rollback the state, but the state is globally consistent. There is a certain probability of the last block rolling back, but the probability is the same for every transaction in that block. In this proposal, the ledger state is just the overlap of all possible transactions, each with its own confirmation probability, and there is no consistent global state.

Design Premise: “The cryptocurrency network benefits from creating a DAG growing as “thin” as possible.

In other words, having the average maximal cut as low as possible. It seems that referencing many previous transactions (high out degree) can make the DAG thinner only if the following transactions reference the transaction with high out degree, but are themselves of low out degree. So we want high out degree some times, but low out degree another times.

I designed a DAG that tries to fulfill that premise, and an associated incentive structure such that:

 There is a benefit for users to reference as many previous transactions as possible
 Referencing many previous transactions is incentivized only when there are many previous transactions unreferenced.
 There is no competition between users to reference a previous transaction.

Here is the paper draft  –> DagCoin-v4 https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf

This same article can be found in my blog: https://bitslog.wordpress.com/2015/09/11/dagcoin/
3  Bitcoin / Development & Technical Discussion / OP_REORGPROOFVERIFY / OP_WITHDRAWPROOFVERIF on: September 11, 2015, 11:13:38 AM
I'm trying to understand the security of the implementation of 2way peg in Elements, but I find almost no official information on how OP_REORGPROOFVERIFY / OP_WITHDRAWPROOFVERIF should work.

It would be very kind if Blockstream releases some basic documentation to the community, so we can learn how it is supposed to work before reading in the code how it is implemented.

Thanks.
 
4  Bitcoin / Development & Technical Discussion / A covert-channel-free black-box signer without ZNPs on: December 14, 2014, 11:47:42 PM
In another thread people are discussing the problems with unauditable implementations of ECDSA (https://bitcointalk.org/index.php?topic=883793.0). Everyone assumes a non-interactive signing method. If you allow interaction, then the solution seems to be easy.

A year ago, when I designed the Firmcoin (Firmcoin.com), I proposed an implementation of a ECDSA signer which uses a random k, but uses a fair coin-flipping kind of protocol to create a k that is private but auditable. In other words, the device and the software in the PC cooperate to create a k value that such that the following properties hold :

1. k is uniformly random and covert-channel-free if the PC software is not backdoored and the device is backdoored
2. k is is uniformly random and covert-channel-free if the PC software is backdoored and the device is not backdoored
3. The PC software cannot obtain the private key.

The full protocol is described here: http://firmcoin.com/?p=52

But I'm copying it here:

The signing of a transaction using the private key is a special two-party protocol. A ECDSA signature consist of the tuple (r,s). All known subliminal channels in ECDSA consist of hiding some information in r. s is computed deterministically from d_A, z and r (except from a single bit, which is the sign of y_1). Our protocol guarantees that r is indeed random.

This is the standard ECDSA signing protocol:

1. The signer calculates e = HASH(m), where HASH is a cryptographic hash function, such as SHA-1.
2. Let z be the L_n leftmost bits of e, where L_n is the bit length of the group order n.
3. The signer selects a random integer k from [1, n-1].
4. The signer calculates the curve point (x_1, y_1) = k * G.
5. The signer calculates r = x_1 (mod n). If r = 0, go back to step 3.
6. The signer calculates s = k^{-1}(z + r d_A) (mod n). If s = 0, go back to step 3.
7. The signature is the pair (r, s) which is sent to the user.

This is our protocol (the user is the PC software the user trusts)

1-2. These steps are similar to the standard protocol.
3. The signer selects a random integer u from [1, n-1].
3.1. The signer calculates Q=u * G.
3.2. The signer calculates h=HASH(Q). This is a commitment to Q.
3.3. The signer sends h to the user.
3.4. The user selects a random integer t from [1, n-1].
3.5. The user sends t to the signer.
3.6. The signer verifies t is  [1, n-1]. The signer sends Q to the user.
3.7. The user verifies that HASH(Q)=h. If not equal, then the signer is cheating.
3.8. The signer calculates k = t * u.
4-7. These steps are similar as the standard protocol.
8. The user calculates the curve point (x_2, y_2) = t * Q.
9. The user verifies that r = x_2 (mod n). If not equal, then the signer is cheating.

This protocol guarantees that the r value is chosen uniformly random from the set of x-coordinates of curve points, and at the same time guarantees that the user cannot arbitrarily force this value.
It must be noted that the protocol should not be repeated unlimited times if it fails. If failure occurs after step 3.5, and not before step 6, because of the signer not responding properly (either providing and invalid message or by not responding at all), then a new iteration of the protocol may allow the signer to leak some information. If the signer fails n times before finishing the protocol properly, then a side channel that hides approximately log2(n) bits may have been tried. For an 256-bit ECDSA private key, we would not recommend executing the protocol more than 16 times if is continuously fails, limiting the amount of information leakage to 4 private bits.

If you find a vulnerability with this protocol please let me know. Also if anyone wants to do a formal analysis of it that would be awesome. As far as I have studied it, it relies on the same crypto assumptions of ECDSA.

Best regards,
 Sergio.
5  Bitcoin / Development & Technical Discussion / Proof of unique blockchain copy stored on: November 05, 2014, 02:54:01 AM
In the thread https://bitcointalk.org/index.php?topic=310323.0 people are discussing how to prove to a peer that one has invested some expensive resource. I was researching on a topic that has some common applications that I think can be useful in cryptocurrencies.

How to prove that one have an unique copy of the blockchain?

This is important for several reasons:

1. It allows anyone to scan the network and check its health, measured by the number of distinct copies of the blockchain in existence.
2. It allows to give higher priority to peers which store the full blockchain (and penalize SPV).
3. It allows to establish a minimum resource consumption to prevent distributed DoS attacks.

The article is on my blog: http://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/

The core idea is to use asymmetric-time functions to store the blockchain in a transformed state (by applying f, which is slow), where the transformation depends on the peer IP address. The data is recovered by applying the inverse of f (which is fast).


6  Bitcoin / Development & Technical Discussion / AttackerSuccessProbability(0.3,1) = 0.627749 on: October 30, 2014, 04:35:55 AM
After some time I gave the Satoshi paper a second read.
I executed the AttackerSuccessProbability() code and computed AttackerSuccessProbability(0.3,1)
(Greg has an online tool to do that here: http://people.xiph.org/~greg/attack_success.html)

The result is 0.627749

Maybe I misunderstood the paper, but this seems to imply that an attacker having 30% of the network hashing can catchup after a 1 block deficit with probability 0.62.
Either this interpretation is incorrect or something in the Satoshi formulae is wrong: an attacker having less than 50% of the hashing power cannot have higher than 50% probability of catching up! That's counterintuitive.

If he had, then the most probably outcome would be that the attacker catches up (in some number of steps).  Since the good branch has more than the double of the attacker hashing power (70% vs 30%) the most probable outcome for the first step is obviously that the good branch mines another block, and not the opposite. So the most probable outcome is that the deficit is increased.

Can anybody clarify this to me?




7  Bitcoin / Development & Technical Discussion / Speeding up bitcoind compilation? on: July 30, 2014, 03:42:27 PM
I'm creating a patch for a bug in bitcoind code, and I'm compiling bitcoind on a Ubuntu virtual machine with 1 GB of RAM and 1 core.

What can I do to speed up compilation?
Will adding an additional core decrease compilation time? Does it benefit from "make -j 2"?
Will adding more RAM decrease it?

Best regards,
 Sergio.

8  Bitcoin / Development & Technical Discussion / Miner accepting non-standard txs required! on: May 27, 2014, 03:58:26 PM
I need to send a non-standard tx. Eligius's  192.3.11.20 seems to be off-line (at least not on port 8333).

Anybody knows a miner/miner pool that accepts non-standard txs right now? Is there another Eligius IP available?

Thanks, Sergio.
9  Bitcoin / Development & Technical Discussion / Faster block rates with DECOR protocol on: May 02, 2014, 05:35:11 AM
Hi!

I wish you take a look at a new protocol I proposed to achieve high block rates and tell me your opinion.
I think it competes or maybe outperforms the GHOST protocol, but I have done no simulations to verify it. I will test it in my http://NimbleCoin.com cryptocurrency and see what happens.

This is my post: http://bitslog.wordpress.com/2014/05/02/decor/

Best regards,
 Sergio.
10  Bitcoin / Development & Technical Discussion / SmartSPV – A better Simplified Payment Verification for Smartphones on: April 25, 2014, 05:09:01 AM
Smart-SPV is a variation of the standard SPV headers-only mode that allows a smartphone to keep a fairly accurate state of the wallet balance without downloading all the missing headers and without sacrificing battery life and time.
The idea is to detect transactions and account them in the client wallet even if the branch where they come is still orphaned.

Here is the description of the protocol: http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/

Best regards!
Sergio.
11  Bitcoin / Development & Technical Discussion / AppeCoin Anonymous Cryptocurrency Draft on: April 24, 2014, 05:32:47 PM
After three years, I'm making public a draft on AppeCoin...

You're invited to break it, because it's probably insecure somehow....

My post about AppeCoin/ZeroCoin/ZeroCash is here: http://bitslog.wordpress.com/2014/04/24/appecoin-anonymous-cryptocurrency-draft/

The draft can be downloaded directly from here: http://bitslog.files.wordpress.com/2014/04/appecoin28.pdf

Best regards!
Sergio.
12  Bitcoin / Development & Technical Discussion / The Private Automatic Miner Backbone Protocol (PAMBA) on: April 19, 2014, 11:32:42 PM
Hello everyone!

The need for direct connection between the main miner pools or solo-miners (which is often called the miner backbone), was discussed several times in the forums.  A miner backbone provides not only benefits to the network as a whole, but benefits for those miners that establish such connections. A backbone decreases the chances of blocks being orphaned, so miners also have a strong incentive to have direct connections between them and announce a solved block as soon as possible.

I tried to create a protocol to allow the top miners to establish such a backbone automatically, without allowing the rest of the nodes to discover the top miners IP addresses.

The full idea is on my post here: http://bitslog.wordpress.com/2014/04/19/the-private-automatic-miner-backbone-protocol-pamba/

Best regards,
 Sergio.
13  Bitcoin / Development & Technical Discussion / MinCen: Consensus in 5 seconds in a p2p cryptocurrency (preliminary paper) on: March 20, 2014, 10:49:40 PM
Hi every one!

This is what I did this week: the MinCen Protocol. The idea is design a cryptocurrency that behaves like a centralized one, but can disperse into fully distributed one if something goes wrong. Nature has many examples of colonies that have a queen, but if the queen dies somehow manage to re-elect a new queen that all obey. This is what the MinCen protocol tries to do: it chooses a master node that decides which is the next block when there are competing chains. Everyone then follows this decision. But if the master node tries to cheat then every miner starts looking for another master node, in such a way that individual decisions converge to a new global selection. Are you designing a new cryptocoin? give a try to the MinCen protocol

The paper and some additional comments are available in my blog here:

http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/


Best regards,
 Sergio.
14  Bitcoin / Development & Technical Discussion / META: Would you like this board be divided into child-boards? on: February 21, 2014, 02:07:10 PM
The forum is the greatest source of information about cryptocurrencies that exists in the Universe.

There are probably tens of thousands of post, but sadly there not well categorized and finding information regarding a certain subject has become too difficult. Academic papers skip adding references to this forum because of the same reason. The same ideas are re-posted over and over again with an average inter-post interval of 4.37 weeks. Also the number of post a day currently is so high that post get kicked out of the first page in the same day they are published and very few people has a chance to read them. I'm pretty sure the moderators cannot read them all now.
Last, some of us like some subjects a lot (such as Security in my case) but have no interest in other subjects (such how to compile the Saoshi client for the Commodore 64), so a sub-division help us use our time more efficiently to answer posts.

Could the admins subdivide this forum into new sub-forums?
Could the admins do a manual or automatic procedure for sub-dividing past threads on this forum into sub-forums?

sub-forum could be:

1. Scripting language and contracts
2. Lost / Corrupted Wallets
3. The block-chain
4. Block interval
5. Security
6. Privacy
7. Satoshi Client compilation/porting
8. Satoshi client releases
9. Core cryptocurrency improvements
10. Importing /Exporting data from the Satoshi Client
11. RPC commands

...etc...


If it cannot be done in retrospective, then we could create the subforums now and start doing it  from now on...

(I offer to do an automatic subdivision of past threads, as long as the admins provide me with an spec on how messages are stored and provide me with a backup file)

Best regards,
 Sergio.



15  Bitcoin / Development & Technical Discussion / How to achieve instant payments in Bitcoin-like cryptocoins on: February 17, 2014, 08:06:25 PM
Here is my last article regarding how a PoW base cryptocoin can achieve a 25 second confirmation time using a 5-second block interval, and still keeping the coin safe from stale blocks and competing chains.

http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/


I think this is the first time such a short block intervals is studied. The techniques I used are not new, but I've managed to simulate the network and convince myself that it actually works quite fine.

I'd love to hear comments...

16  Bitcoin / Development & Technical Discussion / What is block forwarding logic of the Satoshi Client? on: February 10, 2014, 01:36:04 AM
After some time, I'm reading the reference implementation in order to document what is the block forwarding logic, which I have forgotten.
But the logic is spread all over main.cpp.
Could anyone with deeper knowledge answer these simple questions with true/false?

a. An orphan block received from a peer is not announced to the remaining peers until the parents are found ("inv" command not sent immediately).

b. A stale block (not in the best chain) received from a peer is not announced to the remaining peers until it becomes part of the best chain ("inv" command not sent immediately).

c. Some blocks are forwarded even if they are not requested by peers ("block" command issued even if "getdata" not received). Which blocks?

d. Orphan blocks can be requested by peers using "getdata".

e. Stale blocks can be requested by peers using "getdata".

f. Nodes request whatever block it's announced by a peer "inv" command for which they don't have the hash, being stale, orphan or invalid.

Assuming that three Satoshi nodes are connected, what would be the interaction between these nodes regarding received orphan, stale and best-chain blocks?
This link https://bitcointalk.org/index.php?topic=41729.0 describes the interaction, but.. can it be described in more simple words?

I think this information is useful for anyone trying to understand how the actual protocol works. 

Best regards, Sergio.
17  Bitcoin / Development & Technical Discussion / Ethereum “Dagger” PoW function is flawed (technical off-topic) on: January 17, 2014, 07:11:05 PM

One of the features in Ethereum is the use of a PoW function specially designed to be memory-hard. While this may be true (though a formal proof is missing and the design document is quite incomplete), the authors completely forgets another key property a PoW function must provide: it must be sequential-memory hard. This means that not only the function should require large amounts of RAM, but it must not allow easy parallelization. Dagger seems to provide almost the best possible scenario for parallelization. In Dagger, a certain amount of RAM is filled by pseudo-random data derived from the header and the nonce. This data is produced in rounds. Each round, a number of elements from the previous round outputs are hashed together to produce the elements of the following round. These hashes can be performed in parallel. An optimized implementation for an ASIC (or FPGA) is evident for anyone with some discrete logic design background. A speedup from 256X to 2560X seems possible.

I posted more on this issue here:

http://bitslog.wordpress.com/2014/01/17/ethereum-dagger-pow-is-flawed/

My own proposal (SeqMemoHash) solves this problem (http://bitslog.wordpress.com/2013/12/31/strict-memory-hard-hash-functions/)

Best regards,
 Sergio.
18  Alternate cryptocurrencies / Altcoin Discussion / Ethereum “Dagger” PoW function is flawed on: January 17, 2014, 05:21:26 PM
One of the features in Ethereum is the use of a PoW function specially designed to be memory-hard. While this may be true (though a formal proof is missing and the design document is quite incomplete), the authors completely forgets another key property a PoW function must provide: it must be sequential-memory hard. This means that not only the function should require large amounts of RAM, but it must not allow easy parallelization. Dagger seems to provide almost the best possible scenario for parallelization. In Dagger, a certain amount of RAM is filled by pseudo-random data derived from the header and the nonce. This data is produced in rounds. Each round, a number of elements from the previous round outputs are hashed together to produce the elements of the following round. These hashes can be performed in parallel. An optimized implementation for an ASIC (or FPGA) is evident for anyone with some discrete logic design background. A speedup from 256X to 2560X seems possible.

I posted more on this issue here:

http://bitslog.wordpress.com/2014/01/17/ethereum-dagger-pow-is-flawed/

My own proposal (SeqMemoHash) solves this problem (http://bitslog.wordpress.com/2013/12/31/strict-memory-hard-hash-functions/)

Best regards,
 Sergio.
19  Bitcoin / Development & Technical Discussion / Block orphans/day? on: January 08, 2014, 02:57:11 AM
Does anyone know a web page which shows a live statistic of the number of orphans created in a day ?

Is there any paper that presents this information?

Have anyone computed the average orphan rate during last year and previous years?

Best regards,
 Sergio.
20  Bitcoin / Development & Technical Discussion / BitcoinJ node count? on: December 20, 2013, 06:08:16 PM
I checked the page http://luke.dashjr.org/programs/bitcoin/files/charts/security.html which tracks the different clients in existence and I found strange that BitcoinJ (/BitCoinJ:xxx) is not listed (since it's one of the best clear re-implementations of the protocol). I suppose that wallet applications that use Bitcoinj change the id.

Android Wallets may not be much time online, so that may be the reason. There are several that I know are based on Bitcoinj such as "Bitcoin wallet" and  "Blockchain.info".

Any idea?
Pages: [1] 2 3 4 5 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!