 Show Posts
|
|
Pages: « 1 [2] 3 »
|
|
Would you welcome a fork of satoshi aimed to strip it of all but the consensus algorithm, that is without wallet and the RPC replaced with a bus?
Motivation
I recommend using the 'reference' client as border router to the P2P network in production environments, then connect the BOP server inside your company to it, to get a convenient API to Bitcoin in form of a message bus that serves applications and client side wallets.
I guess that above suggestion is not unique to BOP but is how those operate who developed significant added value around satoshi client and wonder if this use case should be the priority for reference client development instead of further extending the feature set of that fragile and crucial code base.
|
|
|
|
|
I am invited to join a panel discussion with local managing directors of MasterCard and Visa at a high profile Finance IT forum on 19. September.
Please feed me any arguments and facts with links you think would be helpful to make Bitcoin shine in comparison. Thanks in advance.
|
|
|
|
May I draw your attention to the payment processor protocol BOP is about to roll out: http://bitsofproof.com/?page_id=467Its goal is to facilitate payment settlement from customer to merchant without the technology provider (BOP) taking possession of the funds at any stage of the process. So it is not a payment processor. The basic idea is simple: 1. Merchant provides a BIP32 master public key to BOP 2. Merchant asks BOP to create payment request 3. BOP draws a random sequence number it uses to derive the key out of the Merchant's Master Public 4. BOP presents customer the address of the key, that is actually an address of the Merchant. 5. Customer pays to the address 6. Merchant pays BOP the processing provision. 7. BOP reveals random sequence number it used 8. Merchant takes funds by creating private key for the sequence. I am thankful for review and comments. The solution will go limited beta on 10. August, and publicly available on 27. August with other tools at the Berlin Bitcoin Exchange. |
|
|
|
Announcing the bop Wallet bop is a lightweight Android client that trusts a BOP Server to retrieve balances, it however stores the private key controlling the funds only on the device. The private key is never transmitted to the Server, transactions are compiled and signed on the device. bop in this early version is derived from BitcoinSpinner and uses BCCAPI. Credits to jan for this great work. I gradually rewrite both the client and API code to further enhance usability and performance. Features (in addition to what you would expect from a Wallet): 1. Switch between BTC, mBTC, XBT (=uBTC) on the fly. 2. HD Wallet using BIP32 that enables it to use unique change address for every transaction. As change position is random and address is not recurring this wallet gives highest privacy while there is no need to regularly backup the wallet since all keys used stem from the same BIP32 master. 3. Backup and Restore by export and import of BIP32 private key. 4. Scan an address QR code and get the balance for that address. 5. Scan a private key to sweep all balances it controls to the BIP32 master in the device. 6. Scan an encrypted private key (BIP38) to to sweep all balances it controls to the BIP32 master in the device. 7. Integration with the BOP Merchant Bitcoin Server .... and more to come. At the moment I am looking for beta tester who would install the built Android package and provide feedback. This will be a commercial product with attractive pricing for the unparalleled usability in your hand. Please contact support@bitsofproof.com for an evaluation access. Evaluators will receive an attractive offer (to be worked out) of the release. Evaluation starts with 21. July 2013. Enhancement suggestions welcome. |
|
|
|
|
According to Bits of Proof node, block 227930 turned on the version 2 block enforcement. Agree?
Edit: Sorry I switched log level and missed it before.
|
|
|
|
|
PLEASE READ BEFORE VOTE
Currencies have popular names like Yen, Dollar and standard names like JPY, USD.
This is not about renaming Bitcoin, but to define a unit for application's UI and database to enhance compatibility and ease of use to help adoption.
It is not about us old Bitcoiners, who are used to Bitcoins' world, but newcomer and the rest of financial software infrastructure.
Alternatives:
1. BTC:
Means: 1 BTC = 100,000,000 satoshis.
For: We got used to it.
Against: Became a pain for small payments since a value of 1 USD is now just about 0.0077 BTC and transaction dust limit is 0.000054. BTC ISO currency code is actually already taken by Bhutan.
2. mBTC and uBTC
Means: 1 BTC = 1000 mBTC, 1mBTC = 1000 uBTC, 1mBTC = 100,000 satoshis, 1uBTC = 100 satoshis.
For: Known idea since long.
Against: Complex for newcomer and non-engineers, not 3 capital letters (not ISO), 5 digits precision needed for mBTC in storage.
3. XBT
Means: 1 XBT = 100 satoshi.
For:
Traditional currencies are dividable by 100 (and not more), therefore virtually none of existing financial databases support currency columns with higher precision, further existing financial software uses 3 capital letter ISO standard code for a currency. This is why it is suggested that the unit should be:
1 XBT = 100 satoshi
that also leads to
1 Bitcoin = 1 million XBT
The notation is handy since:
1,234,567.89 XBT = 1.2 Bitcoin or 1,234 mBTC or 1,234,567 uBTC
The thousand separator helps you to read the other units if you prefer them too. XBT is actually uBTC with an ISO name.
It is XBT because X is used in ISO for supranational currencies and commodities and BT is free.
Against: Let us know.
4. None of the above
Please suggest an other alternative only if you have arguments other than your personal taste to support it and then elaborate.
|
|
|
|
I believe that the bitsofproof implementation at its heart reached beta quality. This is supported by the following facts: 1. It passes most important (address, transaction, scripts) unit tests of the Satoshi client 2. I passes the blocktester created test chains, that are also used to validate pull request of the Satoshi client and part of BitcoinJ build. 3. It runs in sync with the network on my server since months. bitsofproof.com was also sailing through smoothly the recent turbulences. No, this is not yet production quality and no I am not claiming it would be ready substitute to the Satoshi implementation for lots of end user or for miner, and no I am not (and probably never be "done with") testing. But I believe it is solid enough for a developer to experiment building specialized uses with it. In case you are curious you are invited to give it a try. I am still refining the API, also including your feedback, and will add features. I would be interested in usability feedback on the API and bugs you find. You might build run it at your own, or playing with the small explorer demo that I prepared in https://github.com/bitsofproof/supernode/blob/master/clients/demo/src/main/java/com/bitsofproof/client/demo/Explorer.javathat can be run against my server also by using following example options: java -jar clients/demo/target/bitsofproof-clients-demo-0.8-SNAPSHOT.jar remote -- -b <blockhash> java -jar clients/demo/target/bitsofproof-clients-demo-0.8-SNAPSHOT.jar remote -- -t <txhash> java -jar clients/demo/target/bitsofproof-clients-demo-0.8-SNAPSHOT.jar remote -- -a <address> The first two delivers wire format hex dump of the tx or block identified with the hash. The third delivers an "account statement" with starting balance and movements on that address during the last 30 days. (I disabled SD addresses here since a query of millions of UTXO would be a DoS to my server). The API is capable of much more, but lets start here... |
|
|
|
bitsofproof now implements BIP32 (Hierarchical Deterministic Wallets) I plan to store the master key in BIP38 (Passphrase protected private key) format, not yet sure if extra protection is needed for the chain code. Suggestions ? The code supports both extended private to extended private and extended public to extended public generation. If using the second option the merchant server will not have to store private keys for receiving payments on unique addresses generated on the fly. BIP32 code is here: https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java |
|
|
|
Edit: Solved.Mike Hearn pointed me to the relevant comment in bitcoinj. While adapting the bitcoinj block tester to bitsofproof. I struggle to get the meaning of the following comment: FullBlocktestGenerator.java (line 715) // Exploit the SigHash.SINGLE bug to avoid having to make more than one signature Would you please elaborate? What bug? I see that the transaction generated has two inputs and only only output e.g.: { "hash" : "1b4ef446fa472102ceac746719776b763dd7738034345f601258a57e00bc91f1",
"inputs" : [ { "script" : "OP_1",
"sequence" : 4294967295,
"sourceHash" : "725c65ff90a83606f33928761603c9d9f07eb521f5c464b1ddc45dda8ead07f7",
"sourceIx" : 2
},
{ "script" : "0x01ac 0x47304402203fde73d126d8e09349e49d5ed17e18e43c85e9a3a56bfd3a0ccd4da891e0e93102203d5f66ab7886e783ddd7d48b16c85a2ff4a4f9fd32c504ad87dc8928a1c7740103 0x2d21022433dcb55ce46f18d3dd17d66893a7670a4bc059f21897a55af959c75b0717c26ead6ead6ead6ead6eadac",
"sequence" : 4294967295,
"sourceHash" : "b13e5c58e43e3bb2c59d0dccddbf4713c142552bdcca5fcfcb851eab3f86703e",
"sourceIx" : 0
}
],
"lockTime" : 0,
"outputs" : [ { "script" : "OP_1",
"value" : 1
} ],
"version" : 1
}
Reading the Satoshi code I would assume that this does not evaluate to true for input 1 since: script.cpp: else if ((nHashType & 0x1f) == SIGHASH_SINGLE)
{
// Only lock-in the txout payee at same index as txin
unsigned int nOut = nIn;
if (nOut >= txTmp.vout.size())
{
printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
return 1;
}
but apparently it does. Why?
|
|
|
|
|
I seek to gather opinions to evolve a BIP targeting automated compliance check across versions and implementations of the protocol.
The aim is to support two, I think compatible, uses cases:
1. Automated validation of a new release or implementation by challenging it with the help of an accepted one.
2. Ability to validate to-be-mined block templates through different implementations at a major mining side to ensure block templates the work will be committed on will be accepted by several versions and implementations.
I believe the protocol should be a challenge and response. The challenge could include blocks valid for a chain (that will likely be an on-the-fly generated test chain) and/or templates to extend that test chain or the production chain. The challenged node would answer with accept/reject message identifying in case of rejection the reason.
Please contribute your ideas to evolve the requirement, then the definition of this.
|
|
|
|
WITHDRAWN I ask for your feedback on following BIP proposal MOTIVATION Block messages pruned of spent output would reduce chain download time (and its size) by an order of magnitude. PROPOSAL Admit tx messages in blocks whereby the following special form indicates a pruned subtree of the block Merkle tree:
Blocks in this format would be accepted only in chain-download if trailing the last recent block by a significant margin. See follow up discussion for reasoning. The height pruned blocks are accepted until might be regulated by a global rule of checkpointing e.g.
(floor(current_height/1000)-1)*1000. Clients would imply they are at least 1000 behind the head if receiving pruned blocks.
A block can be pruned of transactions spent until current checkpoint height (not until the current head).
version: 1 tx_in count: 1 tx_in: previous_output : hash of the pruned merkle sub-tree script length: 0 (signature script omitted since zero length) sequence: 0xFFFFFFFF tx_out count: 0 lock_time: 0 The node would recognize pruned merkle sub-tree by checking for tx_out == 0 that is otherwise not permitted and use the previous_output hash in its Merkle tree hash computation for tree nodes above this. NOTE: An implementation of the proposal is available for test purposes in the bitsofproof node, link below. |
|
|
|
TL;DR Announcing code release of the bitsofproof supernode. A modular Bitcoin protocol implementation to build bitcoin enterprises and server nodes on. WHY Satoshi is a genius, but his implementation of the protocol is hard to maintain and extend. I believe that peers will specialize and this implementation is suited for the big server, tailored for some heavy lifting tasks, not for a mobile. WHERE https://github.com/bitsofproof/supernode.git FEATURES Pure Java source code released under Apache 2.0 license. Radically modular Assembly using Spring. Extensible and reducible to what you need. High performance P2P engine using Java NIO. Block storage using JPA into a fully normalized schema. Full support for multisig and pay to hash, including address maintanance. Parallel validation of transactions of a block. DEPENDENCIES Spring, Bouncy Castle, SL4J Does NOT share any code with Satoshi or bitcoinj clients. LIMITATIONS Not tested enough for production, therefore does not yet answer getheader and getblock and does not feature a wallet. CONTRIBUTIONS Contributions are welcome. Add your own features to the modular design. WHO Tamas Blummer alias grau tamas@bitsofproof.com wrote this implementation in his spare time at home. DONATIONS Please honor the time I invested and motivate me to continue by donating to: 13xhxy21to93Lrb7d4ssZVaMnFtQVvRkSk |
|
|
|
|
