I feel like most important companies are now go under Colu/Open assets. Are that so much better platform than Counterparty and can that do everything what Counterparty/XCP -"altcoin" can do? I believe the curse of systems like Counterparty is global consensus/state, and to some degree a balance, instead of output based approach. It adds a lot of overhead and fragility. |
|
|
|
I implemented stealth payment and address into NBitcoin. (.NET library for Bitcoin dev)
For what I have seen, the BIP is just a formalization on paper of what already exist, I'm not sure this BIP is essential at all, just a nice to have.
Isn't a written formalization probably always just "nice to have"? A specification for BIP 63 could serve as starting point for alternative implementations. But FWIW, since it wasn't mentioned before in this thread: https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth |
|
|
|
mining hardware has little to do with the issue, besides the fact that if large blocks are slow to download it could allow large miners to [unintentionally] start creating small forms while the slower miners create orphans. The mining process is virtually unchanged Sorry, poor choice of words. I wasn't thinking about mining hardware, but deploying additional bandwidth/adjusting hosting plans/[...] and alike, to handle larger blocks. |
|
|
|
i think as long as it averages over at least 1-2 weeks, thats sufficient to prevent any sort of rampant spamming. I'm not sure, if "how long can spam last" covers the whole picture. I'd like to ask "how fast can miners deploy new hardware/adjust to an increased cap?" in addition. |
|
|
|
MediciCTO Oh, that one. I assumed it was a troll, too. Now in retrospective, the post history is pretty telling: (4 months ago) Medici is evaluating all crypto technologies.
(4 months ago) Medici is still evaluating crypto technologies. We continue discussions with Counterparty, however, we do not plan to limit our platform to a single blockchain, ledger or protocol. The long-term future of crypto securities will undoubtedly include multiple exchanges. Medici will enable trading where ever efficient and qualified exchanges can be created.
(4 months ago) Security, performance, and throughput are some of the considerations when looking at cryptoexchanges. We remain interested in technologies (including the bitcoin blockchain) that might efficiently enable transparent and distributed securities settlement.
(2 months ago) Medici will support multiple cryptotechnologies....counterparty may eventually be one of them, but that is far from certain. Trading platforms have a very specific set of requirements and we will be using the best of the available protocols/technologies.
(2 months ago) The Medici platform is intended to support multiple blockchains/crypto-ledgers. We want to work with the solution which best fits the requirements specific to our use-cases. It appears to be certain that Counterparty wasn't the only horse in the game, and it seems likely that OpenAssets isn't going to be the only technology used either. |
|
|
|
So far I like this proposal very much, too. I'm for Gavins simple 20MB kicking-the-can-down-the-road proposal. With the rollover penalty in place I might be willing to wait longer and let some pressure build on developing scaling solutions. The elastic cap, penalty fee pool and the hard limit could be addressed seperately, although it probably makes not much sense to introduce this mechanism with the current block size limit. In this context I'd like to add some visibility to TierNolan's post on the second page: ... increasing the block size requires a hard fork, but the fee pool part could be accomplished purely with a soft fork. It seems viable to set a high hard limit, and start with a lower-than-max elastic cap, which could be increased further at some point in the future. |
|
|
|
I love the counterparty project but I think Overstock and others went for colored coin because
4) Nasdaq will use Open Assets My very best guess: the news about Nasdaq and Overstock might be connected. I tend to believe it makes sense to use a colored coins like system for plain settlement, due to the much lower overhead, compared to global consensus systems such as XCP. It's clear that this comes with significant limitations though. |
|
|
|
Whatever happened to this? I'm a bit surprised, too. This is the relevant comment: Hey there, do you guys build on Counterparty (meta layer on top of Bitcoin)? No. We're using the Open Asset protocol. Specifically, Circle Colored Coins. Edit: SALT LAKE CITY, June 5, 2015 (GLOBE NEWSWIRE) -- Overstock.com, Inc. (Nasdaq:OSTK) became the first company to solicit qualified institutional buyers in a digital corporate bond which will trade using the same technology that underlies cryptocurrencies such as bitcoin. This pioneering development is part of the company's larger cryptofinance initiative known as Medici.
"The cryptorevolution has arrived on Wall Street," said Overstock.com CEO Patrick M. Byrne. "We're making it official by offering the world's first cryptosecurity."
Byrne went on to explain that a cryptosecurity is one that trades on a cryptographically-protected distributed ledger. In this case, buyers will be able to track their ownership on the bitcoin blockchain.
The issuance is powered by Overstock.com's TŘ.com technology – a name that refers to the fact that trades on the system securely settle same day, as opposed to three days later -- or what Wall Street traders refer to as, "T+3". The TŘ.com technology uses the Open Assets protocol.
According to Byrne, issuing the TIGRcub bonds on the TŘ.com platform proves that cryptotechnology can facilitate transparent and secure access to capital by emerging companies. Byrne added that a circular informing investors of the cryptobond offering was distributed on June 1, 2015.
This offering is being made exclusively to qualified institutional buyers that meet the definition of "accredited investor" in compliance with Rule 506(c) of Regulation D under the Securities Act of 1933, as amended. http://investors.overstock.com/phoenix.zhtml?c=131091&p=irol-newsArticle&ID=2056957 |
|
|
|
If T=3MB it's like a 6MB limit with pressure to keep blocks smaller than 3MB unless there are enough transactions paying fees so it's worth including them?
I think T should scale over time as bandwidth is growing. 42 transactions per second is still a low limit for a global payment network.
As far as I can see, and given that: Obviously increasing the block size requires a hard fork, but the [penality] fee pool part could be accomplished purely with a soft fork. Then it would be possible to raise the block size limit to 6, 20, 40, ... MB, but introduce a soft cap and a penality mechanism for "large" blocks. The penality function (and thus soft cap) may be freely adjusted over time, as long as the resulting block size doesn't exceed the hard limit. The process will resemble climbing a hill rather than running into a brick wall. Very well put, I like it. |
|
|
|
My goal is at least to maintain something like 14 tx/s in total tx on the network for a month. (with estimated fees for 3 block confirmation)
Just to put it in some perspective: With a size of roughly 250-350 kB per transaction, that's about 4000-6000 BTC spent in total for fees, with estimatefee 3 = 0.00044247 BTC/kB, and 14 tx/s for one month. That makes this idea seem like an insanely expensive experiment! How could this ever be a feasible thing to pull off if dexX7 is right about these costs? It should be noticed that "estimatefee", a Bitcoin Core command to estimate fees to pay, seems a bit high, when it suggests to pay 0.00044247 BTC/kB to get a confirmation within 3 blocks. And further, 14 tx/s is about 10x the transaction volume we currently see, assuming those transactions make it (which they wouldn't). But either way, I agree, even with some magnitudes cheaper costs, this seems expensive.  NB: what is your goal anyway? Disturb the network and delay legit transactions? I'd would feel more comfortable, if those experiments use rather low fees instead, so that regular transactions are mostly unaffected, or require only a small fee bump. |
|
|
|
My goal is at least to maintain something like 14 tx/s in total tx on the network for a month. (with estimated fees for 3 block confirmation)
Just to put it in some perspective: With a size of roughly 250-350 kB per transaction, that's about 4000-6000 BTC spent in total for fees, with estimatefee 3 = 0.00044247 BTC/kB, and 14 tx/s for one month. |
|
|
|
Does this mean that Bitcoin is pretty vulnerable against vandalism? What happens if someone is pushing giga bytes of text into the blockchain? Does text pushing to the blockchain cost more than a normal transaction?
Publishing 1 GB of data, assuming a standard fee of 0.0001 BTC/1000 byte transaction size, roughly costs 170 BTC, if the data is embedded via P2SH, as done here. |
|
|
|
Posted a day ago: Note to self, testnet is being mined heavily with almost 10,000 blocks in the last 24 hours |
|
|
|
It is not too difficult to create a tool to get data as a plain text from these transactions (but I do not have interest to do it) Speaking of tools ... http://bitcoinstrings.com/blk00251.txt |
|
|
|
|
Keep in mind, and I'm not saying this is the case here: there is always the chance that high profile accounts are hijacked, bought or otherwise used to orchestrate a specific opinion. Echoing the OP by fresh accounts can serve as further indicator. If there is any suspicion, it may help to compare the sentiment of the message with post histories, to spot irregularities.
|
|
|
|
It's probably worth to mention: don't restart the client inbetween, when you have many unconfirmed transactions. During startup, when adding pending wallet transactions, which spend outputs of
other pending wallet transactions, back to the memory pool, and when they are
added out of order, it appears as if they are orphans with missing inputs.
Those transactions are then rejected and flagged as "conflicting" (= not in the
memory pool, not in the block chain). https://github.com/bitcoin/bitcoin/pull/5511 |
|
|
|
|
Interesting!
Is it possible to provide one of the signing keys, or add other inputs, and would it be possible to bind an event to more than one transaction output, or different script types than pay-to-script-hash?
|
|
|
|
|
Show Posts
