 Show Posts
|
|
Pages: [1]
|
Hi, I can help test mining. Computer 1 - Xeon E3-1545M v5 @ 2.9Ghz
64 GB RAM
Ubuntu derivative
Chrome and Firefox
Computer 2 - i7-6700K
16 GB RAM
Windows 10 Pro
Chrome, Firefox, Edge
Mobile - Snapdragon 835
4 GB RAM
Android OS 7
Chrome, Firefox, Edge
|
|
|
|
What else can the exchanges do? The most recent blocks show that the attacker is still minting away, see the 100 XZC transactions: https://chainz.cryptoid.info/xzc/block.dws?21758.htmhttps://chainz.cryptoid.info/xzc/block.dws?21749.htmThe transaction is a Zcoin Spend which moves money from the private pool to the public pool. The attacker's fraudulent Zcoin Spend transactions are being accepted as valid by nodes when instead they (and the block) should be rejected as invalid. I don't think the bug is due to a simple typo. I believe it's somewhere in the implementation of the verification code, which looks like its full of repeated blocks of copy and paste code. Posted more info here: https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/In terms of resolution, the following would be prudent: To demonstrate that the bug has been fixed, all the fraudulent Zcoin Spend transactions found on the blockchain should be run through a patched CheckTransaction and detected as invalid. |
|
|
|
And when you've done that, tada you have segwit (specifically, you get the _exact_ construction that was used in elements alpha). But a version of it with a ugly construction that requires every Bitcoin speaking program to upgrade _simultaneously_, and invalidates any pre-created nlocktimed transactions which _will_ confiscate some amount of users' Bitcoins (because some parties have been signing payments then destroying private keys as a time-lock-safe mechanism).
Isn't this a user problem rather than a protocol issue? First, the protocol doesn't specify that a user must destroy their private key when creating nLockTimed transactions. Second, since there's no guarantee that any given transaction will ever be successfully mined, it doesn't seem prudent to pre-sign transactions which sit off-chain and only become valid for broadcast and potential mining in some distant future whilst also deleting the private key. If this destructive behaviour can be condoned, it beggars belief that zero conf transactions are considered unsafe. |
|
|
|
As for malleability, so anyone wanna say why that can't be done properly on it's own without segwit?
Fair question as the signature malleability issue is quite simple to fix. When hashing the transaction data to generate a txid, simply skip over the signature data. Everything else stays the same. Deployment and activation would be via a hard fork set at a certain block height. |
|
|
|
Are you thinking of building your next project with Ethereum, Rootstock or some other smart contract platform? Before you start investing resources, take into consideration some fundamental problems with smart contracts on public blockchains. https://makebitcoingreatagain.wordpress.com/2016/02/10/5-challenges-facing-smart-contracts/TLDR... - No guarantee of transaction execution
- Turing-complete smart contracts are slow
- Scaling is a moonshot
- Oracles break the trust model
- Public blockchains struggle to stay decentralized
|
|
|
|
Please fuck off with your bullshit.
He is right, some developers want BTC to become some sort of elitist piece of shit where fees may become more and more expensive to the point it's used only by people buying millions. This would be a catastrophe and those devs seem to not care. @AtheistAKASaneBrain Partially :-) I'm not advocating for this change, just trying to let you guys know what is happening. honestly i don't see anything that needs changing. you are saying that the "fee market will likely develop" but there is no change in the fee market! it has been as it was before.
@pooya87 @AtheistAKASaneBrain Some Bitcoin Core developers want to keep the block size at 1MB to encourage a fee market to develop, and ultimately have Bitcoin become a settlement system where the majority of transactions occur off-chain on payment hubs and sidechains. In such a situations, any attempt to send a free or low-fee transaction on the public blockchain will likely be discarded or face significant delays. Thus some developers feel it is wrong to continue to promise free and fast transactions: Other developers believe the block size should be raised to increase the capacity of the system and help keep fees to a minimum, which is more in line with the original vision of Bitcoin as a fast P2P cash system without intermediaries. |
|
|
|
|
Er, don't shoot the messenger.
|
|
|
|
Some developers no longer want to imply that Bitcoin offers cheap and fast transactions since a fee market will likely develop: The current site text makes repeated mention of Bitcoin providing low transaction fees and instant transactions, as well as strongly implying that any transaction paying a fee or having medium priority will be confirmed in the next block.
As instant transactions can be unsafe and the other things are less likely to be true in as available block space becomes fully utilized, this pull removes or clarifies those sections. Link with screenshots of proposed changes: https://github.com/bitcoin-dot-org/bitcoin.org/pull/972 |
|
|
|
If you mouseover the CoinSpark link you can see what kind of transaction it is. In this case it's a Genesis transaction, so you (or somebody else) issued one unit of an asset to a CoinSpark address (which is just a wrapper around an underlying Bitcoin address). If the issuer uploads the PDF contract and HTML file to the website path, the SparkBit wallet for the CoinSpark address will validate the asset and then it could be sent onto someone else.  |
|
|
|
You can send messages over Bitcoin with CoinSpark (an OP_RETURN based protocol). http://www.coindesk.com/coinspark-blockchain-notarized-messaging/Messages are not stored on the Bitcoin blockchain itself but are sent out-of-band via message delivery servers. When you send a message with a bitcoin transaction, the blockchain only stores enough details for the recipient to retrieve the message and ensure it is valid. CoinSpark runs some community servers but you can run your own server and modify it to meet your needs as the code is open-source. Get started by downloading SparkBit, a lightweight SPV wallet based on MultiBit: http://www.coinspark.orgDevelopers can find open-source libraries and docs here: http://coinspark.org/developers/messages-introduction/ |
|
|
|
1) You might put a diagram or schematic in to illustrate a Bitcoin Asset and/or a Bitcoin Gold Asset
Hi orobtc, Just wanted to let you know: Cheers!  |
|
|
|
1) You might put a diagram or schematic in to illustrate a Bitcoin Asset and/or a Bitcoin Gold Asset
2) Similarly, show us an example of a wallet tied to, say, a 1/10th oz gold coin (this is a common small sized bullion coin)
Thanks OROBTC, that's a good idea. Is a high-level view sufficient - where Bitcoin is treated as a black box - or do you think readers would benefit from a bit more detail? I think dropping down to OP_RETURN and transaction outputs might be too much. |
|
|
|
A common complaint from gold investors is that the benchmark price of physical gold, set twice daily in London by a handful of banks, is open to manipulation. There is currently a lawsuit underway concerning such allegations and the benchmark is due to be replaced in early 2015 because of incoming financial regulations stemming from the LIBOR scandal. With the emergence of Bitcoin as a platform to transfer assets other than BTC, I believe that if entrepreneurs and gold stakeholders were to support the development of investor products based around gold-backed Bitcoin assets, a new price benchmark for physical gold could emerge. With the bulk of the world's gold production and consumption now in Asia, and new gold exchanges having launched there recently, Bitcoin could help tip the balance, and we could enter a new era where the price of gold is no longer influenced so much by London. For some, this would be liberation. I have put together a short paper to explore this topic, including how to create a new Bitcoin asset in just a few minutes and why these assets are superior to existing gold instruments. It's currently a working draft and your feedback is most welcome. Please feel free to comment here or within the Google Document itself. Thank you! https://docs.google.com/document/d/15VG1f8Jwkl6eKLsqGv1KdUUgVRkQleaXr33JgDL-4So/edit?usp=sharingNote: I am involved in a Bitcoin assets project, within the colored coins family, called CoinSpark. You can find out more here: http://www.coinspark.orgUpdate: Example diagram showing how GoldCo can securitize their gold holdings as Bitcoin assets
|
|
|
|
|
